Hi *, On Tue, Jun 07, 2005 at 05:18:53PM +0200, Joerg Barfurth wrote: > Christian Lohmaier wrote: > >On Fri, Jun 03, 2005 at 12:33:34PM +0200, Joerg Barfurth wrote: > > >>For the second point: it is > >>tedious to do this, but the rfe_eval flag/process can be the vehicle to > >>do it. > > >But why do you spend time on something that leads to nothing? > > How do you know that it won't?
That was not a statement that it would lead to nothing. But this is the impression I and others got. If you see zero progress (really zero, nothing at all) you conclude that it is not worth spending time on this effort since your contribution doesn't speed things up. Again this may not be true (and I hope it is not) - but this is the state as of now. > >This is the big problem why evaluating (=quality controlling) of the > >RFE-process has "stalled". > > I can see that you'd like faster responses. But apparently that is not > the way Sun UE organize their work. And that is why a new process was introduced. That is why I made the review-proposals even before that new process was introduced. But the new process did not help at all, it did not change the handling of RFEs. So why should this new process be useful? > Meanwhile presorting and enhancing > RFE issues is the one thing you can do to prepare things for the time > when RFE processing is resumed. But this is not the goal of a RFE-process. This is just general qa-work, nothing special to RFEs. I don't want to evaluate 2000+ issues only to have 1800 of them ignored again. > >>Which is sort of dangerous. I know that queries for 'no target milestone > >>assigned' are sometimes used to find issues that need this kind of > >>evaluation. > > >In the case of RFEs no TM has been processed at all in the meantime. > > Again: I don't know how Sun UE organize their work and have no influence > on that. Nobody knows. But again: UE doesn't set the target-milestones. UE doesn't respond to issues. > I also don't know what 'in the meantime' refers to. In the meantime: After planning for OOo 2.0 has ended up until now. You can take "from the very beginning of IssueZilla until now" as well since only few issues reported by regular users have been processed by user-experience during planning. Most of them were handled after planning finished and the issues matched "by accident". > But if I > were in UE, I'd start by looking through issues without target milestone > (to decide between <next release>, Later, PleaseHelp and WONTFIX). Again: This decision is not being taken at all. Again: When I write "no action, no decision at all", I really mean "no decision at all". > [...] As you write: You're not UE and cannot influence this. > >>[...] > >>OTOH, waiting for super-reviews used to be one of the main bottlenecks > >>in contributing to mozilla, iirc. > > >AFAIK auch a review was necessary for every contribution, every patch to > >assure the quality of the code (not to break other things). This whole > >area is covered by CWS-QA in OOo. > > I probably meant that if stuff is now stuck assigned to requirements, it > might then end up waiting for super-review. So it all makes sense only > if you find suitable super-reviewers that are willing to make this a > success. No. It makes sense to only apply the review-process to a selection of issues. That's why there is a first review-step to sort out the issues, to reduce that number to a reasonable value. Again: It would be a progess if UE would decide upon one issue per month. The review-thing is *not* meant to be the standard way of handling issues. It is meant to get a handful of issues handled faster than others (or have them hanled at all). > >>True. But this already happened to a degree. But we have (or had?) very > >>long designated feature or UI freeze phases. And in those phases - and > >>even a certain time before the deadlines - little room for decisions > >>remains. > > >Nobody said that you have to consider the issues for the current > >release. > > Apparently that is the way the UE people work: they only look over > issues when there is a release they could put it into. But you know there will be a release after the current one. > [...] > OTOH, if we take community RFE work seriously, why couldn't the > evaluation and classification be done by 'community RE'? It is only the > "*we* (Sun) will/may/won't do this" part that requires decisions by Sun. That is what the whole process is about, but Sun doesn't take this decision. > And these decisions are very much driven by resources and internal goals > for the next release(s). And where's the problem in taking this decision before the current release is out of the door? > >>Try changing/influencing it *before* feature/UI freeze! > > > >The issue was filed before UI freeze! (june 2004) > > Which one? The quickstarter one. The other issues I mentioned were filed *way before featurefreeze*, they were filed against OOo 1.1.0 or even against earlier versions. > [...] > Where do I say that this is internal? > > In our process the i-Team is responsible for the spec, because all roles > represented there (UE, Dev, QA, Docs) are affected by the spec and must > contribute and ultimately affirm with their approval that the spec > fullfills the requirements and is sufficient for implementation, > creating tests and documenting the feature. > > If you don't have a full i-Team, you can still do the initial writing. > But you should have an understanding of the development process and of > the target audience of the spec. You basically wrote: Often only the i-team knows the problems/background so only the i-team can write a sensible spec. This is "internal". But you still don't see the same problem as I do. You keep talking about step 4 & 5 but still step 1 is missing. (Don't take this literally, there is no listing of these steps). To get on the real topic again: * Community needs a way to influence and veto a spec using a defined process * RFE-Handling has to be revamped completely. Currently, instead of filing an issue you could as well write your proposal on a sheet of paper and place it under that big stone in your garden. With the same effect. ciao Christian -- NP: Helloween - Eagle Fly Free --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
