No, you're right, I don't see open.silverstripe.org mentioned in the guide, only the obscure 'issue' number :-)

But since we're supposed to report fixes, patches and feature requests on open.silverstripe.org, l think that using the ticketnumber is the best way to link the fix to the problem, instead of opening issues on some other location. Every contribution starts with something being broken or desired, so creating a ticket, or responding to an existing ticket would be the first step anyway...

Others are doing this as well - see the following commit as an example:

MINOR: group ShowInMenus and ShowInSearch check boxes. Fixes #6901 [wilr]

referring to http://open.silverstripe.org/ticket/6901

I think part of the problem I have been working on some fixes for the blog module.

Checking open.silverstripe.org, there isn't a component setup for blog, and issue logging on GitHub is enabled...

Possibly the blog module hasn't been updated to match other Silverstripe components?

I think as long as it's contributing to the silverstripe core (where issues on github are not open) referring to tickets should be ok. For modules - probably raising an issue is the way to go and referring to that issue in the pull request should be ok too, but how to catch that snake biting its tail I wouldn't know... :-(

That sounds like a good analogy to me!

The way I see it is that you create an issue if you don't have the fix for it. If you do have the fix for it and there's an existing ticket on trac (or whatever the module is using), then reference it. Otherwise the pull request itself is usually enough.

For example. https://github.com/silverstripe/sapphire/pull/435 was in response to a ticket on trac, so references it (should've been referenced in the commit message too, but that wasn't standardised yet) whereas https://github.com/silverstripe/sapphire/pull/240 was fixing a bug that didn't have an associated ticket already.

Especially with the modules that use github for issues, discussion has to happen on github so creating an issue just so you can immediately create a pull request that fixes it is superfluous. However, major new features should probably be discussed before they get implemented, so a ticket/issue and a post to the ss-dev mailing list should happen before a pull request.

Long term ideally we're moving away from trac. Just be big mission to move the 1100 tickets!