Re: Could we track actions with github issues?

Norm Tovey-Walsh writes:

> Hi folks,
>
> I recognize that this incurs a slightly higher administrative overhead,
> but I think it would have benefits. I would like to move to a model
> where the actions we generate in meetings are recorded in GitHub issues
> and resolved by individual pull requests that address those issues.
> (With the understanding that sometimes issues are closely related and we
> may end up with a single PR that fixes more than one issue.)

Count me as a yes vote on this.

Just one question: how does this work for actions that don't involve
changes to something in the repo?

And I'll add more generally that I think it would help if we could also
adopt the practice of someone updating issues we discuss in meetings to
point to those minutes and summarize the discussion.  I find it slightly
bewildering to pull up an open issue to review its status and find that
the issue in the issue tracker has no record of discussions -- or more
important -- resolutions agreed on in a meeting.  I sometimes try to
repair such gaps, but not always.

(I never much expected to miss Bugzilla, but its built-in status codes
for workflow -- new, assigned, needs-review, etc. -- made it much easier
to keep track of which issues needed discussion and which were open only
because we were waiting for the required change to be written, or
because the draft change needed to be reviewed and approved, etc.
Perhaps the Labels feature in Github would be useful -- although there
doesn't seem to be a way to sort all open issues by label[s].)

For what it's worth, the way the XML Schema WG managed issues used a
sort of two-pass approach: first the WG discussed the issue and
attempted to reach agreement on the right technical solution.  Then the
spec editors had drafted spec wording and prepared a change proposal (in
which the changes to the language were marked up so people could see
exactly how the wording was changing).  Then the WG reviewed the wording
and agreed to the change (or not, in which case either the editors
needed to re-draft or the WG needed to re-discuss to re-establish
agreement on the solution to use).  Then the changes were integrated
into the current draft.  And then the issue could be marked closed.
(Once we had gone to last call, there was an additional step of asking
the person who raised the issue whether they were willing to accept the
resolution of the issue, and giving them two weeks to respond, before
closing the issue.)

That meant that any given issue could be in any of several statuses:
new, in need of discussion by WG, awaiting drafting, awaiting review,
awaiting publication, awaiting review by originator, and closed.  The
Query and XSLT WGs used as I recall a slightly different work flow, but
it was useful in all cases:

  - to have a common understanding of the work flow
  - to have a step in which proposed wording changes are reviewed
  - to use the issue tracking system to keep track of where each issue
    was in the work flow

This has gone a bit further than my original goal of saying "+1" to
Norm's suggestion, but I will offer it for what it's worth.

Michael


> I observe, for example, that the minutes of the 22 March meeting say
> that Steven resolved eight actions. But I have no easy way of
> identifying what those actions were or how each was resolved. (I
> appreciate that I can look at previous minutes, but that’s not always
> terribly clear (I feel free to say that in part because *I’m*
> responsible for the previous meeting minutes)). And since we don’t have
> change tracking for the spec, I can diff the 22 Feb draft and the 17
> March draft, but I can’t tell which changes were related to which
> issues.
>
> For what it’s worth, this is how the XProc CG manages the XProc drafts
> and it has worked very well for us.
>
> The discipline of managing issues this way would make it easier for
> reviewers to track changes to the spec and to the test suite. It would
> also tie in nicely with continuous integration as we could have a public
> “editor’s draft” that reflects all the pull requests that have been
> merged. And then we could use tags to publish official updates to the
> status quo.
>
>                                         Be seeing you,
>                                           norm


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

Received on Wednesday, 23 March 2022 18:07:18 UTC