[JOSS] Number scheme is not explained about scores

[savente93]

That's fine, you don't have to change anything about that. Even something saying like "some contributors like to disambiguate branches by prepending a number which GitHub can do for you when creating branches based on issues, but this is not required" would be sufficient in my eyes. It is mostly just to make sure new contributors don't feel like they are missing a crucial step.

The numbering is not intended to filter whether tests are run - we expect the tests to run on every branch.

My bad, I misread your workflow config. I think I confused on: pull_request with on: push so you can disregard that bit.

The branch "228-documentation-testing-branch" is used differently to everything else in scores. This is a working branch which is used as a space to see how readthedocs will render a change. As such, it will change frequently and never be merged directly. Only some developers are comfortable building the docs locally, and also there are still potential differences between a local build and the eventual rendering in readthedocs.

I think this is a lovely mechanism, I think it would be good to mention that in the documentation as well

[tennlee]

Thanks. There is not a lot of formality to the numbers - they are generated by default by GitHub for some branch creation workflows based on issues, and we (or I at least) find them somewhat helpful. I'll add some explanation to the contributor's guide, but nobody should feel obliged to use them, and you don't need to try to follow any scheme during the review process.

The numbering is not intended to filter whether tests are run - we expect the tests to run on every branch.

The branch "228-documentation-testing-branch" is used differently to everything else in scores. This is a working branch which is used as a space to see how readthedocs will render a change. As such, it will change frequently and never be merged directly. Only some developers are comfortable building the docs locally, and also there are still potential differences between a local build and the eventual rendering in readthedocs.

I find the branch numbers very helpful in distinguishing similarly-named or ambiguously-named branches, but it's a feature intended for the human eye and no automated processes rely on or use the branch numbering. It is also somewhat historical as most of the core team was originally using branches on the main repository, however as we move to a fork-based workflow, the numbers are less relevant and no longer created by default.