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.

General Questions /

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

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

Contributing on GitHub


Go to End
Reply


14 Posts   942 Views

Avatar
martimiz

Forum Moderator, 1105 Posts

16 August 2012 at 2:20am

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

Avatar
Mo

Community Member, 510 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 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?

Avatar
martimiz

Forum Moderator, 1105 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... :-(

Avatar
Mo

Community Member, 510 Posts

16 August 2012 at 4:32am

That sounds like a good analogy to me!

Avatar
simon_w

Forum Moderator, 474 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. [url]https://github.com/silverstripe/sapphire/pull/435[/url] 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 [url]https://github.com/silverstripe/sapphire/pull/240[/url] 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 [url=http://groups.google.com/group/silverstripe-dev]ss-dev mailing list[/url] should happen before a pull request.

Avatar
Willr

Forum Moderator, 5513 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