Difference between revisions of "Talk:IssueHandling"

Latest revision as of 14:05, 13 February 2008

Comments on the current version of the proposal (2008-02-13)

• I welcome the general idea
• I don't really get the table :) (I get the content, but the tabular form is a mystery to me)
• setting the target when the issues is assigned to a CWS sounds too early to me. In case of shifts of issues, or other changes in plan, you would need to care that the target is reset, or set to a new one, and so one. Bug potential for inconsistencies, IMO.
• The decision which keywords (aka: issue classes) automatically qualify for the next release is good as general idea, but:
  • "usability": All other classes, by definition, are important to be fixed for the next release. The "usability" class, OTH, falls into this category by consensus only - and this consensus might change. Similar, there were times were performance was considered to be of really high priority - at this time, issues with the keyword "performance" would have qualified automatically. In other words: Let's be careful with global automatisms here.
  • "release_blocker" isn't really consistently used. Before promoting it.. we should clearly define how it is used, when, and by whom.
  • "crash": This isn't really used. Some people set it, most don't, so it becomes effectively useless
  • In other words: Perhaps we should not focus on keywords, but on classes of issues. Keywords are intended to denote the issue's class, but they're seldom properly used.
  • The keyword "loop" does not exist
  • Well, perhaps once keywords are promoted this way as suggested here, this is a new motivation to actually *do* use them properly.
• In general, let's be careful with the "3.x" (or any y.x) target. It turned out this didn't work for 2.x: we had way too much, so we needed to retarget *a lot* to 3.x. Actually, this should not have happened, since 2.x was defined as "issues which should be fixed for 3.0 or earlier, if possible at all" (or something like this). Nonetheless, it happened, because it was used way too careless. The current proposal implicitly seems to suggest (at least this is my reading between the lines), that we can solve our target problem with using the ownership problem. I don't think this will be the case.
• Additionally to the criterions suggested in the proposal, we should also mention that it is absolutely legitimate to grab an issue from the "unassigned" pool, if you for whatever reason decide to work on that issue, or plan to do so in the forseeable future. The reasons for this may not be related to the "automatic" reasons at all.
• We should mention who is responsible to ensure that important issues don't rot in the "unassigned" pool. That is, if somebody submits an issue describing a crash - who is responsible to finally ensure that it becomes assigned? In practice, this might be a mixture of QA, development, and some automatisms - but who is the person to finally blame if the number of such wrongly unassigned bugs exceeds, say, 20? You get the idea ... (I hope)