Re: Process wonkery

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:16:08 UTC