Managing our issues list (discharges action QT4CG-038-01)

Hello,

At the time of this writing, there are 149 open issues on the QT4CG
issues list. (We have closed 159, so by at least some metrics, we’re
winning!)

An issues list serves many purposes.

1. It tracks bugs in the spec: X is wrong.
2. It tracks missing features in the spec: X isn’t possible.
3. It tracks requests for enhancements: we should do X.
4. It tracks questions: how do I do X?
5. It identifies the work that remains before we can declare victory:
   there are 149 more issues to resolve.

Perhaps in an ideal world, an issues list would serve exactly one
purpose and we would all agree on it. We don’t live in that world.

Compounding the problem is that, for any given issue, it’s not always
clear which category it belongs to. Someone reports a bug (X is
wrong). Someone else comments that it isn’t a bug (X is right). That
becomes an assertion that a feature is missing (ok, but then Y isn’t
possible). That becomes a request for enhancement (Y would be possible
if we Z). Etc.

There’s nothing wrong, per se, with issues that document a question,
its various answers, the features that could be added to make it
easier, their counter-proposals, etc. Those are useful and the context
they provide can help educate readers and inform the decisions of the
group.

But I think that the salient feature of *an issue* that is relevant to
a working group is that it documents “a vital or unsettled matter”
(Merriam-Webster).

That is, that it documents a matter on which the working group must,
or should, or at least *could* take action. If there’s no explicit
action that can be taken to resolve an issue (fix X, document Y, add
Z), then it isn’t really an “unsettled matter”. It’s something else.

I would like to close issues that cannot be resolved by taking some
action. A closed issue is still in the issues list, it can still be
read, it can still be found by searching, it can still be referred to
in an email. A closed issue isn’t gone or deleted. To be candid, I
don’t see how a closed issue is any less accessible than an issue on
page 6 or 16 or 600 of the issues list.

The counter-proposal made during the meeting yesterday was to label
the issues as “unactionable” in some way but leave them open. From an
entirely technical perspective, that’s equivalent. I can filter out
messages labeled “unactionable”, I can ignore them when constructing
agendas, I can treat them as “closed” for the purpose of generating
our burn-down charts.

But I would still prefer to close issues that are unactionable. I
think that closing issues aids the community in understanding our
progress. If a user comes to our repository and discovers that there
are 200 or 25 or 2 open, actionable issues, they have an immediate
sense of how much work remains to be done. If they find 200 open
issues but in fact 175 of them have an “unactionable” label, I fear
that they will neither see nor understand the significance of that
label and even if they do, it will not be obvious that only 25 are
actionable without some effort on their part. And they will have
formed an opinion at first glance that we’re a long way from being
finished because there are 200 open issues.

I took an action to make a proposal, here is my proposal.

Everyone is encouraged to review our issues list. In doing so, you may
propose to organize issues into one of three groups: “unactionable”,
“necessary for 4.0”, or “nice to have, but it could wait”. It *is not*
necessary that every issue be in one of these groups. Many issues will
remain open and subject to more discussion before this grouping can be
applied. That’s ok.

1. If someone reviews an issue and determines that there’s nothing
   actionable in it, they can add the “Propose Closing with No Action”
   label.
   + Periodically, we’ll put those on the agenda.
     + If everyone agrees, we’ll close the issue.
     + If someone disagrees, we won’t close it without action.
       + In that case, I propose that the default action should be to
         open one or more new issues that identify specific, unsettled
         matters that could be resolved. Those new issues can link to
         the old issue for context. Then we close the old issue. I
         think this is *particularly* important for issues that have
         long comment threads with different and overlapping
         discussions.
       + (Obviously, if you see an item on the agenda that’s proposed
         for closure and you disagree, you’re encouraged to
         proactively create some new issues before the meeting.)
2. Anyone who reviews an issue, determines that it is actionable, and
   feels strongly that it is a critical requirement for 4.0 can add
   the “Propose for V4.0” label.
   + Periodically, we’ll put those on the agenda.
     + If everyone agrees, we’ll add those issues to the QT 4.0
       milestone.
     + If someone disagrees, we’ll try to come to some consensus about it.
3. Anyone who reviews an issue, deterimines that it is actionable, but
   thinks it is not on the critical path for QT 4.0 can add the
   “Propose for V.next” label.
   + Periodically, we’ll put those on the agenda.
     + If everyone agrees, we’ll add those issues to the QT Future
       milestone.
     + If someone disagrees, we’ll try to come to some consensus about it.

Does that sound fair and reasonable?

                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica