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

For what it's worth, this seems like a good idea to me.  I have a few
small comments:

- When I learned the word 'actionable', it was apparently used only in
  legal contexts and denoted things that might become the subject of a
  legal action:  an 'actionable' remark might be something you said that
  could land you with a suit for slander.

  So I would be very grateful if someone were to come up with a word we
  can plausibly use to mean 'suitable for acting upon', other than
  'actionable'.  So far, the online thesauruses I have consulted have
  let me down.

  If we cannot find another way to exress the idea, I will do my best to
  learn to live with 'actionable'.

  In the context of an issues list, I think 'actionable' means 'capable
  of being resolved satisfactorily', or 'capable of being resolved by
  the group making a decision', so perhaps 'resolvable' or 'decidable'
  would work.

- I assume that one reason to close an issue with no action is not that
  it's undecidable, unresolvable, or non-actionable, but just that it
  proposes something that we decide we do not wish to do.  So I guess
  that "propose to close with no action" can be *either*

    - a way of marking an issue as too broad (perhaps because it has
      grown too many legs in its discussion) and not resolvable with a
      single decision, *or*

    - a way of deciding an issue ('we will do nothing').

  If that's not the case, I will need some re-education.

Thank you, Norm!

Michael

Norm Tovey-Walsh <norm@saxonica.com> writes:

> [[PGP Signed Part:Undecided]]
> 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


-- 
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
http://blackmesatech.com

Received on Thursday, 15 June 2023 16:35:07 UTC