I think that's a good clarification, and sends the message that no contribution is too big or small as long as the appropriate route is taken. It might also be nice, for the various scenarios, to have links to some example issues/PRs (e.g. #2327) that demonstrate the process.

For more complicated changes that might require core team input, maybe making use of the "Allow edits by maintainers" feature would help? Its a fairly obscure option that I've never made use of before, but might offer an easier way of changing external PRs without a whole bunch of merges. That may not answer the docs building question though.

While we're on the subject of contributing guidelines, I noticed an outdated link in the guidelines for opening a new bug report. https://mrtrix.readthedocs.io/en/latest/troubleshooting/advanced_debugging.html is dead, I guess the equivalent wiki page is this one?

Looks good, no issues from my point of view. The only thing I would say is that starting with an issue before making changes might be advisable to avoid the faff that switching merge targets can otherwise entail. If the user makes changes based on master and submits a PR, but we subsequently suggest this should be merged to dev, this can sometimes be a messy process (typically best done with a cherry-pick and a forced push, or a whole new PR...). It would be good to somehow convey this issue so users understand why starting with an issue might save them a lot of time down the track...

And I also agree that "allow edits by maintainers" feature should be encouraged! It would make all of our lives much easier if we could push suggested changes directly to the relevant branch...

In terms of generating the docs on other branches: it's trivial for branches on our repo, not so trivial if they're on other repos, as far as I can tell. It can be done, but it essentially involves setting up a whole new project on readthedocs - not difficult, mind you, maybe we can provide that as a suggestion? Otherwise, the simplest would indeed be to duplicate the user's branch on our repo, and yes, the simplest might be to re-use the doctest branch since it is automatically built (though I might disable it on the main readthedocs site, and enable it on the mrtrix-dev project instead). We can have any branch we want built, we just need to enable it on the readthedocs site.

And thanks for spotting the dead link, @fionaEyoung! I think the link you've identified is indeed the relevant one. We'll get that fixed ASAP - unless you beat us to it... ;)

Aha! I hadn't realised editing an issue template was even an option...

The only thing I would say is that starting with an issue before making changes might be advisable to avoid the faff that switching merge targets can otherwise entail.

Agreed; revised.

And I also agree that "allow edits by maintainers" feature should be encouraged!

Given this can be engaged after the fact, I don't think it needs to appear in the contribution document; we can simply make the request if need be.

In terms of generating the docs on other branches:

I've removed that component entirely. Somehow forgot the fact that one can do a local rendering for such verification purposes.

Looks good to me, thanks!

One minor point though: while local rendering is possible, I've certainly had issues with it from time to time (probably mostly due to using a bleeding-edge distro like Arch Linux, though). Pushing to a branch and having readthedocs render it is much easier, especially for users less familiar with python and pip. But then, the right place to mention this would be in that docs/README.md document, not necessarily in the issue template...

If there's a reasonable chance of a rendering issue, we can always at our end generate a new branch here based on the fork and set that up to render on readthedocs. But it's maybe too esoteric an issue to be waffling on about in the contributing guidelines.