Hi *, On Fri, Jun 03, 2005 at 11:13:24AM +0200, Joerg Barfurth wrote: > Christian Lohmaier wrote: > >On Thu, Jun 02, 2005 at 03:54:31PM +0200, Joerg Barfurth wrote: > >>Christian Lohmaier wrote: > [OOoPleaseHelp-Issues] > >That is exactly the idea behind closing it. Get it out of the way, leave > >the issues that are being worked on/that have not yet been decided upon. > > There are many different roles in this project, which do different > things with existing issues. Some examples > > 1. Look for existing issues > a) before submitting an own one > b) during evaluation > 2. Confirm, evaluate and dispatch new issues > 3. Look for issues to implement > a) during release planning > b) as independent developer > 4. Plan and track your development work > 5. Track the feature status/quality of releases in progress > > In this selection each task has a different set of issues with which to > work. > > The issues we are talking about are not at all relevant only for 2. and > 4. They are very relevant for both 1. and 3b). These two tasks are often > done by newcomers with limited experience in dealing with issuezilla. > Thus our issues really should not be closed and should even be included > in the default queries.
I disagree. With the same reasoning you shouldn't close fixed issues or duplicates (for 1). Furthermore: I as independent developer would just query for "OOoPleaseHelp", no solutin necessary. I can be sure that I don't duplicate any work and that the work I'm going to make will be accepted for the product. This is not the case for unevaluated issues. Regarding 4) This task is done by a small group of people. Have them use a dedicated saved query instead of forcing every else to do so. For 4) A "catch *all* issues that match" if far more likely than the average query that limits the results to issues containing "summary/description". Same goes for 5) > If you regularly do activities like 2. and 4. you probably will set up > saved queries adapted to your needs anyhow - so excluding issues having > the 'OOo PleaseHelp' target or marked RESOLVED/LATER would be trivial. > Otherwise you can still easily adopt the habit to deselect it every time. Saved queries only help partially - if you want to query for varying summaries/descriptions a saved query is far from usable (with dial-up connection). Loading a query is just too damn slow. The only way to work with IssueZilla and lots of different queries is to use your browser's cache in this case - and this only works with one standard-query. Having a look at the list of target-milestones you'll notice that deselecting it is not that trivial. It is annoying sice you'll always have to scroll the list and to spot the entries you don't want. > >>It might be assigned to a dummy owner and/or we might use the useless > >>RESOLVED-LATER status for it, but we should not close it. > > >I disagree, mainly because of working on the open issues gets easier > >when the issues that nobody's working on are not in the way. > > If a developer looks for issues he could take on, he will look at things > that are still open, rather than closed (i.e. dealt with for good). >From my understanding (Sun-paid) developers don't look for issues on their own, they take the ones assigned to them by UE. Since UE already has decided that this is something that is not appealing for Sun to do by itself, they don't have to bother with those issues. "Independent" developers have a singe thing to look for: The OOoPleaseHelp-target. If they want all, they can setup a dedicated query that defaults to both or adapt an existing query for their current session. Looking for issues to implement is far less usual than looking for issues because of other reasons. > >If you don't close them, you'll have to exclude the target OOoPleaseHelp > >in every query again and again.. > > It depends on the goals of your query. And yes, the initial query > defaults in issuezilla will not suit every role. Yes. And I say: It is far easier to have the few people to have special queries than to force the majority to do so. > >>The most important characteristic of such an issue is that > >>- it is OPEN > >>- it has target milestone OOoPleaseHelp > > >My opinion is: Open issues are those that some action is going to be > >taken. > > Open issues are those on which some action may be taken. Closed issues > are those on which no action will be taken any more. If you have a > current issue that looks duplicate to a closed issue you should > generally submit a new one. The closed one is done. So where you see the difference? Don't confuse the TM with the keyword needhelp. The OOoPleaseHelp-issues are de-facto "dead". Unless someone picks it. In this case it is reopened -> worked on. Unless the situation changes and picking such an issue for implementation gets the usual thing (instead of nobody working on it), then the policy can be changed to leave those issue open. But if only 1 issue out of 300 OOoPleaseHelp issues get worked on, closing them is more "honest" and more reasonable IMHO. > >To me it doesn't make sense to have issues open that nobody > >is/will be working on. Leaving it open may signal to the reporter that > >the issue is handled. > > >Closing it makes clear that unless someone > >interested takes care of the issue, it will never see the light of day. > > 'resolving' as LATER (or something similar) or leaving as NEW and > setting a 'target' of 'PleaseHelp' should be clear indications that the > issue is not being handled currently and that it probably won't be done > unless someone jumps in. This will be understood by those familiar with the process. But just look at the reality. People don't know the current states of issuezilla, they don't know what Resolved means, they don't know what a target-milestone means. IssueZilla is foll of complaints, reopening of resolved fixed issues. "Hey, you said it is fixed, but my OOo still crashes". No wonder it still crashes since the fix is only in a cws and not integrated. An indication that is only understood by "insiders" doesn't help at all. But I can take your argument and convert it to mine. 'Closing' an issue with target 'OOoPleaseHelp' should be a clear indication that the issue is not being handled currently that it probably won't be done unless someone jumps in. For the user not familiar with all that different meanings it is clear that: Closed -> "too bad, seems like I have to live without that feature if I cannot find other peple interested in this" But New woul mean "Hmm, has bee a long time since I filed this issue - what is going on? -> 'Hey * -any action on this issue? Do you need more info?' -> Hmm, still no response -> 'Helllooo?! Somebody out there?' -> [EMAIL PROTECTED] deaf opensource developers!" > BTW: I've seen cases where such issues were fixed by the responsible > developer after all when working on the relevant section of the code or > were taken into account when a related feature was specified, because > the requested change was no extra effort. Don't tell me that they queried issueZilla to find that issue that is related to the thing they were fixing. These are those issues that I was referring to as "fixed by 'accident'" Developers may look for related defects, but not for related RFEs. > For this to occur, it is > useful to keep it in sight of the developer. And if the issue was > already closed, you'd never notice that. As priorities and goals change, > such issues may even be taken over actively by Sun developers after a while. Nobody prevents those who are in charge of evaluating the RFEs, setting teh priorities to include the OOoPleaseHelp issues. > >Closing it with an appropriate comment may even result in the reporter > >searching for "independent" developers actively while such "pressure" is > >not createn by leaving the issue open and letting it rot... > > It shouldn't rot without comment or target. But target milestone and > status are the correct fields to express the state of a non-resolved issue. And I still disagree. OOoPleaseHelp is the correct field, but an non-resolved issue dosn't have to stay open. My POV is still that only issues where work can be expected to be done in near future deserve the right to stay open. Everything else should be sorted out. ciao Christian -- NP: 4Lyn - Poonanee --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
