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

> 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 like "resolvable".

Though all these qualifications are quite subjective. What is :resolvable"
or "decidable" to one person may not be such to another.

We need to have rules on how to "resolve" such conflicts, and I hope at
least this is "resolvable" :)

Thanks,
Dimitre

On Thu, Jun 15, 2023 at 9:35 AM C. M. Sperberg-McQueen <
cmsmcq@blackmesatech.com> wrote:

> 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
>
>