[development] "I'm disappointed by the freeze"

[Chris Cook]

On 2/22/06, Robert Douglass <rob at 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