Re: [native-lang] Update: Sun/NLC meeting

Hi Andre,

Andre Schnabel wrote:
> Well .. the RFE process is (imho) very complicated an something that 
> will take a *very* long term to get feedback. Although it is obvious to 
> me, that this is a "Must be" for long term planning, it is something 
> that fit's not very well with the community style. As we work with 
> volunteers, who's intention ist often just "fun" , we should make it
> - simple
> - fast

The problem is to reconcile this with the idea of having 'long-term' 
planning. And we have to remember that this is a product targeted at 
end-users of vastly differing backgrounds and needs.  Thus 'simply' and 
'quickly' realizing someones 'fun' enhancement is often not a good idea. 
One persons fun-filled enhancement is a nuisance or worse for others. We 
have seen this happens even to enhancements where experienced user 
experience engineers were involved. Because of this we need a process 
that reconciles related RFEs and evaluates the impact of the changes.

> and we should
> - relase early
> - release often
> 

We do. Biweekly releases (our milestone builds) are really often for a 
product this size. If you want early and frequent releases then you 
shouldn't stick to a branch that is dubbed 'stable'. That one is for 
people who don't want changes coming in quickly.

The problem we had was really that for a long time the development 
branch was far from usable for daily work. We need to avoid first 
breaking the entire product badly and then fixing the breakage over a 
long time. Many developers agree to this idea now and the 'child 
workspace' (CWS) development model provides the means to achieve this. 
The other side of this medal is that we need to keep new features in 
their CWS off the main branch until they are stable enough to not break 
the product.

> The RFE-process startet. We had people, who worked on the first stages 
> (look at Christian's mail). But after that, not much happened. But this 
> is a problem of the process (no, I don't want to blame Sun for that).
> Again .. I know, this needs time (if we work in the futere, as we work 
> now). But we don't need to start a process with such "planned delays", 
> as we would get people frustrated.
> 

Working on processes is tedious, takes a long time and the necessary 
resources must be diverted from work that is immediately productive. 
That makes it difficult to plan and finish as planned. It may be easier, 
if there is a natural point for process change, like our impending move 
to the next release(s).

>>> Honestly saying, I don't really know, why I care about issues, that 
>>> could be resolved within minutes .. 
>>

>> How do you know that? If you know, why don't you resolve them 
>> yourself? Do you have examples? Do you consider that changing the user 
>> interface requires more than changing the code (e.g. specifications, 
>> documentation, translation).
> 

> Well .. Robert gave an example, another was the quickstarter.
> A (not that important but frustrating one) is here:
> http://qa.openoffice.org/issues/show_bug.cgi?id=46289
> I even don't know, if this is easy to fix, or if tooke the right way, as 
> there has been no answer.
> 
> And why don't I fix it by myself? Because I try to fokus on bug hunting 
> / qa. I tried for a very long time to do "as much as possible" witin 
> this project .. and ended up frustrated (and burned out).
> I really would like to fix some simple things by myself .. but how, if I 
> get no answer or guidance?
> 

Admittedly some of the developers are less responsive to such issues 
than others. If you don't understand the choice of target milestone or 
don't get an answer to a question you might try PM to the owner instead 
of adding IZ comments. If you think you have a stopper or want to raise 
the priority of an issue you may also write to the [email protected] list or 
contact the project lead.

> And .. sorry to say that. I'm with this project for about three years 
> now and I think, I know a part of this project (so I don't feel, I'm a 
> community beginner). I've been subscribed to several lists, trying to 
> get the idea, what should belong where and what could be resolved where. 
> I won't do this agian, as I really felt, my head got bloated.
> 

There are many people on this project and different people have 
different communication styles. Often there are old habits that are hard 
to change. There probably is not one single way of communicating that 
works with everyone. This makes working in this project difficult. But I 
have no good idea how to change this.

Ciao, Joerg

-- 
Joerg Barfurth              Sun Microsystems - Desktop - Hamburg
 >>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer                         [email protected]
OpenOffice.org Configuration          http://util.openoffice.org