Style:
welcome to bbDKP.com Downloads Tracker Development Demo 1 FreenodeIRC
Developer
Sajaki
Developer
level ?? boss
level ?? boss
Posts: 2266
Joined: 28 Dec 2007, 14:56
Location: Ulduar

[POLICY] Social coding : third party code Submissions

Postby Sajaki » 26 Nov 2010, 19:38

Hello,

If you are a coder and would like to enhance bbDKP and would like it to be integrated in the core, that is now possible. :)

This is our new policy for submitting contributions and patches to code : When you want to submit a patch, there are two methods :

  • Via Github :
    1. open a Github account
    2. fork any of the projects from https://github.com/bbDKP, that means the Main bbDKP project, and any of the plugin projects.
    3. create a feature branch in your fork, numbered with the ticket number, for example "apply-branch-ticket123"
    4. program your change. To ensure a consistent code base, you should make sure the code follows the Coding Standards which we borrowed from phpBB.
    5. Once you are finished with your work, you just push your changes to your own personal fork on Github.
    6. (optional) tell us about it : make post in the User Modifications forum, or make a ticket here : tracker
    7. In order to have your code integrated in the core, issue a pull request on Github.
    8. This allows us to review your changes, comment on them, etc.
    9. once the review is complete and approved, it is merged in the core. You will of course be credited.
  • Manually :
    you could also simply post your changes here in the User Modifications forum, but that will mean more work for us to integrate it in the core, delaying your code contribution.

Developer
Sajaki
Developer
level ?? boss
level ?? boss
Posts: 2266
Joined: 28 Dec 2007, 14:56
Location: Ulduar

Re: [POLICY] Social coding : third party code Submissions

Postby Sajaki » 16 Aug 2012, 11:13

Hi,

I've updated our Github Patch guidelines for contributors :

  • Follow the style of the existing code.
  • One commit should do exactly one thing.
  • Commit messages should start with a summary line below 80 characters followed by a blank line, and then the reasoning/analysis for why the change was made (if appropriate).
  • Commits that fix a bug in a previous commit (which has already been merged) should start with [fix] and then the summary line of the commit it fixes.
  • Rebase your branch against the upstream’s master. We don’t want to pull redundant merge commits.
  • You agree that your patch is automatically licensed as GPL v2 by sending us a pull request.