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 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...

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.