Hi *, On Fri, Jun 03, 2005 at 12:33:34PM +0200, Joerg Barfurth wrote: > Christian Lohmaier wrote: > >On Thu, Jun 02, 2005 at 05:39:37PM +0200, Joerg Barfurth wrote: > >>Christian Lohmaier wrote: > [...] > >This is true for defects, but not for RFEs (at least not in practice). > > It should be. If this isn't true in practice, we need to (a) clearly > define and communicate the meaning and workflow for RFE states and (b) > clean up the backlog of issues that don't fit the rules. For the first > point: afaik there is an RFE workflow document on the qa site. Maybe it > needs to be improved or communicated better.
You can assume that all issues with rfe_eval_ok (=were evaluated according to the process) are OK. > 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? This is the big problem why evaluating (=quality controlling) of the RFE-process has "stalled". > >>- Our target milstone definitions are not clear enough or > >>- Our target milestone usage has not been communicated well enough > > >I cannot tell what the reasons is, I can only tell that I cannot > >determine any difference between these target milestones when it comes > >to RFEs. > > There clearly is a difference between, "we hope we can do this later" > and "noone has taken any decision on whether or when this should be > done". Which also applies to RFEs. If past practice did not honor this, > we should change that practice instead of giving up the definitions. First we need these definitions. > >>The use of "not determined" is certainly underspecified. I can think of > >>at least two vastly different meanings. > > >True. I for myself used that milestone for issues that I evaluated > >according to the new process, hoping that the evaluated issues would get > >handled sometime soon and get a real target (or rejected) > > 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. > I have used it (very rarely) for issues where an acceptable patch was > there, but the decision about the target branch/release was still open > or for issues where the target branch was known, but the target release > was unclear (e.g. I needed someone outside Sun to verify a change in > their build/port, but noone did). Then you should have used the needhelp (and maybe the needmoreinfo) keyword as well. > >>That might make sense. But apparently the proposal did not reach the > >>right people (yet). > > >Given the fact that I came up with this a couple of times and mailing > >lists (including the dedicated proddev-ML) I doubt it wil reach the > >"right" people ever. > > If you know who the relevant people are, you might try PM. The link you > gave to proddev hat this buried at the end of a mail deep into a thread. If Bettina Haberer and Erwin Tenhumberg are not the right people (both are subsribed to proddev list, Bettina posted to qa a couple of times as well) > [...] > 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. > >>>But this renders the RFE-process pretty useless. > > >>No the triaging and cleanup process can go a long way to ensure that > >>there is good material when the next planning session starts. So when > >>the time comes everyone can work on the real meaty stuff instead of > >>having to sift through the accumulated junk. > > > >OK, it is not completely usesless, but bad RFEs should not have been > >reassigned to requirements/bh in the first place.. > > True. But then again, the difference should really be whether a target > milestone is assigned. Having this special owner helps monitor all RFEs > in the queue, including those where initial triage is still in progress. Before requirements the special owners were "bh" and or "ft" - No gain. And again: The problem is that there is no action at all, not even setting a target-milestone by UE-pople. The TM is set by those who reassign the issue. > >This "plan once for the whole release" is a big problem. It would be > >much easier, transparent, satisfying if this would be a more continuous > >thing with only the big changes planned beforehand (e.g. rewrite > >chart-module, get rid of table-row limit, change table-handling in > >writer, change toolbar concept,..) and leave room for decisions during > >the implementation of the big issues, depending on how fast (or slow) > >they proceed. > > 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. > >A shorter release-cycle has similar effects, so I'm all in favor of > >shorter release-cycles (more minor releases, not only major (does take > >looong) and micro (only bugfixes)) > > A shorter release cycle should also mitigate the effect of the long > freeze phases. Freeze phases are irrelevant since it is not about getting the feature into the product as fast as possible. It is about getting response, feedback on the issue. Having the RFEs classified honestly. > [...] > >Why does a long release cycle imply > > ######---------------------------------------######------ > > ~~~~~~+++++++++++++++++++++++++++++++++++++++~~~~~~++++++ > >### planning phase, RFEs are evaluated > >+++ implementation phase, ~ maintenance/bugfixing, > >- no progress on RFEs at all. > > > >Why can't it just be > > ######---##---#--#---##--#---#--#----##-----#-######--#--- > > ~~~~~~++++++++++++++++++++++++++++++++++++++++~~~~~~++++++ > > > > I think reality is more like > ######----#---##---#----X-------------------#--|######--- > ~~~~++++++++~+~+++~+++++X+~++~~+~+~~~~~~~~~~~~~|~+~++++++ > > where X marks feature/UI freeze and | marks the release. So the long > freeze phase is part of the problem. No. When you finished planning for the current release, you can start planning for the next one during feature freeze. Planning in this case doesn't mean: "Assign ressources" but "work on the issue, evaluate it, classify it"-> Decide. > And prior to the freeze most > community efforts still concentrated on the stable version and trying to > get stuff added there (which again is due to the long release cycle). It is not about getting existing stuff in (this is another point, but totally different). It is still about getting decisions. > AFAICT many of the disputed issues came up after or very shortly before > the freeze(s). But again this deals with a different point (the vetoing/shaping of issues) and not about the no-decisions problem (RFEs lying around for years without any response). > >>>Another decision that can be taken easily almost everytime is > >>>"needs a complete rewrite" vs "just like fixing a typo" > >> > >>This one is an engineering judgement, not something a user experience > >>guy can necessarily judge. > > >Not for every issue, that's true, but there are many, many issues that > >only affect the UI, some request a different wording or similar. Even > >this kind of issue is only part of the pile (=sits there forever) > >although you'd only have to replace the word "foo" by "bar". Same is > >true for the opposite. Implementing new chart types surely is more work > >than changing a string or resizing/reordering a dialog. > > > > True. But the latter two involve more than meets the eye: linguistic > review, usability review, localization, documentation. That is why there > is a UI freeze (which implies string freeze). And after that freeze such > changes take extra effort (and may incur extra cost), so there is high > resistance against such changes. See above. I think we're not yet talking about the very same thing. My concern is to get the RFEs "handled" (decided upon), not getting them implemented/integrated into the product. An answer like "We're already at feature freeze. We take this issue but it will have to wait for the next release" is perfectly OK and all I want. What is not OK is having an issue filed in 2003 and then in 2005 comes the first comment "too late, retarget" Before I can complain about features not getting into the product, the problem leading to this situation (no answers on RFEs) has to be sorted out. The review-system is to deal with both: Both getting an answer quickly and to have it integrated as fast as possible. (It you would not consider it important enough, you would not have proposed it for review) > >What really bothers me is the following: > >When you cannot change a small (implementation wise) point of a spec > >with clear arguments, how could you influence spec only by request, > >user-feedback, votes alone? > > Try changing/influencing it *before* feature/UI freeze! The issue was filed before UI freeze! (june 2004) > >>>>Such changes need not only a patch, but a specification - or an update > >>>>to the existing specification. > > >>>Nobody asked for such actions. And these things are old but still > >>>unresolved (except the font in math's command-window) > > >>If an issue is from an unfamiliar community member, I generally (have > >>to) assume that the submitter won't be able to do that themselves. > > >Nobody is saying that the reporter should supply one. If this really is > >a problem, then a page "So you were asked for a spec..." could be > >created. > > Not sure I understand you. Generally the team that 'owns' the feature - > and that will implement it - (the i-Team) creates the spec. Generally > the reporter will not be expected or asked to do this. But every feature > needs a spec and doing this properly is work. You wrote above: "such changes need[...]specification" I responded: Nobody asked for such info. Then you said: You cannot expect the casual submitter to understand what a spec is about, so I said: create a page that explains all these (with informatin why a spec is needed, where to get help creating one, etc). But then you write this is an internal thing so again the problem was not about missing informatin in the issue but the lack of decision from Sun that the reporter/community could not influence. > [..] ciao Christian -- NP: Metallica - (Anesthesia) - Pulling Teeth --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
