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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
