- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Thu, 24 Mar 2022 09:17:29 +0000
- To: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
- Cc: public-ixml@w3.org
- Message-ID: <m21qyr1z17.fsf@Hackmatack.fritz.box>
> Just one question: how does this work for actions that don't involve > changes to something in the repo? We can still use an issue to track it, we’ll just have to close it by hand when we think it’s finished. (Pro tip, if you write a PR for issue #99 and you include “close #99” in the description of the PR, merging the PR will automatically close issue #99.) > 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 Yes, if we adopt using issues to track actions, we should summarize meeting discussion in comments on the issue. > 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].) No, but you can filter by them. > 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 I’ve managed a similar kind of workflow using GitHub issues with the following conventions: 1. Use labels to filter issues (V.next, editorial, etc.) 2. An open issue with no one assigned to it is in need of discussion. 3. Assigning an issue to a person is effectively giving them an action to draft a resolution 4. The draft resolution is implemented as a PR 5. If the WG accepts the PR, it’s merged and the issue closes. With CI, merging the PR kicks off a job that builds and publishes a new editor’s draft accordingly. Be seeing you, norm -- Norm Tovey-Walsh Saxonica
Received on Thursday, 24 March 2022 09:27:16 UTC