On 2/22/06, Robert Douglass <rob@robshouse.net> wrote:
The PROPOSAL:
This may not be the time or place to comment but I have some opinions on this subject which I have voiced in the past. I'll comment below.
Adjust the user privileges and workflow of the issue queue so that there are, in fact, two queues: -- the first queue is the mess we now know and love. Everything goes into it and it is everyone's task to evaluate the issues. The difference is that there is a user role that has the extra-magical-superhero power to promote an issue to the second queue.
It isn't really clear to me what you mean by a queue. We currently have 10 status' which may be applied to an issue (which could be considered as queues if one knows how to use the search form). Are you suggesting we need a separate field to designate which queue an issue is in? There would be problems with doing this but it is also unnecessary as I'll explain below.
In summary, the most important two aspects of my proposal are: 1) there is a user role that is more empowered to make decisions about patches than they are today. This group of trusted developers has the magical power to promote an issue to the "pressure cooker". 2) the "pressure cooker" organizes the queue into wheat and chaff. When Dries reviews patches, he knows that unless someone trusted has promoted it into the pressure cooker, he doesn't need to fool with it (he still can if he wants, of course). This will negate the "pester-Dries-on-IRC" necessity since any issue in the pressure cooker will automatically get his attention. It also galvanizes the community around the issues in the pressure cooker since it is clear that those are the issues being taken seriously, the ones that are likely to "make it".
First of all, we are in agreement that project.module needs improved access control to support better issue management and prevent misuse of some states. As far as your idea of queues though, unless you're speaking of them in some metaphorical sense which would have no impact on the system itself, I disagree with the approach for a couple of reasons. First, having queues is against the idea of the node concept. I should be able to find a list of all nodes with properties x, y, and z (priority being one of those) and not have to think in terms of queues. This would lead to tunnel vision in my opinion. Second, the "list of pressure cooker issues" which you describe above could easily be a pre-defined (or better yet user definable) search. Third, queues would only help core committers but would leave the rest of us in the cold. The idea to make Dries job easier should play a primary role but Dries is not the only player here. Issue management functionality is currently lacking for all users. For example, anyone including anonymous users can currently create an issue and modify it to any state. Issue states are ambiguous (this is a whole discussion unto itself) and priorities are not well defined or presented to the user. Issue search is not perfect. The fact that "anyone" can set an issue to "ready to commit" status is the problem. Not a lack of queues. My proposal (which I've written in the past) would, in short, be the following. 1. Add access control such that certain status values (and possibly other properties) are restricted to certain roles. 2. Further define and disambiguate issue status values. 3. Add a "resolution" property. 4. Perhaps in the long term add pre-defined and/or user-definable searches. This proposal would provide the following. 1. Issues would no longer be permitted to be elevated to "ready to commit" status by anyone but allowed roles. Core committers could be certain that a search for that value would result in only issues that had been reviewed and accepted by a moderator. 2. More clearly defined status values would provide greater transparency to "actual" issue state and greater search flexibility (e.g., "find all unconfirmed bugs", "find all bugs being not being worked on"). 3. A resolution property would allow us to identify "why" a bug was closed. We currently have no less than 4 different "closed" status values (i.e., won't fix, by design, duplicate, closed) when we should have only one. Cheers, Chris