- From: Bethan Tovey-Walsh <bytheway@linguacelta.com>
- Date: Tue, 7 Jul 2026 11:39:32 +0100
- To: Steven Pemberton <steven.pemberton@cwi.nl>
- Cc: public-ixml@w3.org
Agreed, both with Norm's original suggestion and Steven's comment. BTW ___________________________________________________ Dr. Bethan Tovey-Walsh linguacelta.com Golygydd | Editor geirfan.cymru Croeso i chi ysgrifennu ataf yn y Gymraeg. > On 7 Jul 2026, at 11:16, Steven Pemberton <steven.pemberton@cwi.nl> wrote: > > Sounds like a good idea; which means that in a meeting when we decide on a change, it should not just be recorded as an ACTION, but also as an issue. > > Steven > > > > On Monday 06 July 2026 17:24:41 (+02:00), Norm Tovey-Walsh wrote: > >> Hello, >> >> I don’t want to be the guy who throws up a bunch of arbitrary process hurdles, but I do *have* one process suggestion. I think we should agree that pull requests that change the specification be in service of a particular issue, and they should identify that issue. That means, >> if you want to change the spec: >> >> 1. Make an issue describing the problem. Let’s say it’s issue #1234. >> 2. Make a pull request that you believe addresses the issue. Include the string “fix #1234” or “close #1234” in the PR description. >> >> That will link the PR and the issue and if the PR is merged, it will automatically close the issue. It’s a nice bit of automation from the repository. >> >> If our “V.next change log” then lists all of the pull requests that went into the new version, it leaves a clear trail for someone to follow if they want to know what, when, and why a change was made. >> >> Of course, in most cases, it’s going to make sense to wait for discussion between steps 1 and 2, but maybe not for editorial issues. >> >> -- >> Norm Tovey-Walsh >> CEO, Saxonica >> >> > > > >
Received on Tuesday, 7 July 2026 10:39:52 UTC