Last visit was: less than a minute ago

It is currently 20 Jun 2013, 22:54

[POLICY] Social coding : third party code Submissions

Stuff the management is working on
phpBB DEV topic.
Sajaki
Development Team Leader
User avatar
Posts: 2171
Joined: 28 Dec 2007, 14:56
Location: Belgium

[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 , 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 :
    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.
Top

Sajaki
Development Team Leader
User avatar
Posts: 2171
Joined: 28 Dec 2007, 14:56
Location: Belgium

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

Return to News & Announcements

Who is online

Users browsing this forum: Internet Archive [Bot] and 0 guests

  • Advertisement