Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

Contributing on GitHub

Go to End

14 Posts   1534 Views


Forum Moderator, 1391 Posts

16 August 2012 at 2:20am

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

But since we're supposed to report fixes, patches and feature requests on, 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


Community Member, 541 Posts

16 August 2012 at 2:34am

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

Checking, 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?


Forum Moderator, 1391 Posts

16 August 2012 at 4:20am

Edited: 16/08/2012 4:22am

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


Community Member, 541 Posts

16 August 2012 at 4:32am

That sounds like a good analogy to me!


Community Member, 473 Posts

16 August 2012 at 10:09am

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


Forum Moderator, 5523 Posts

17 August 2012 at 8:03pm

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

Go to Top