Process wonkery

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 Monday, 6 July 2026 15:24:47 UTC