deblan/phpci
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity
Page: Maintainers
Pages
Add a Virtual Host Adding PHPCI Support to Your Projects Atoum Plugin Autobuilding from Atlassian Stash Autobuilding from Git by Cron Autobuilding From Git Autobuilding From GitHub Autobuilding From GitLab Autobuilding from Bitbucket Behat plugin Campfire plugin Clean build plugin Codeception plugin Composer plugin Configuring PHPCI Contributing to PHPCI Copy build plugin Deployer Email plugin Env plugin Example phpci.yml Grunt plugin Hipchat Notify Plugin Home Installing PHPCI Interpolation Irc plugin Lint plugin Logging Maintainers MySQL plugin PHP Code Sniffer plugin PHP Coding Standards Fixer plugin PHP Docblock Checker PHPCI Config Package build plugin Pdepend plugin Phar Plugin Phing Plugin Php copy paste detector plugin Php loc plugin Php mess detector plugin Php parallel lint plugin Php spec plugin PhpUnit Plugin Postgresql plugin Project Status Images and Page Run Builds Using Cron Run Builds Using a Daemon Run Builds Using a Worker Shell plugin Slack Notify Plugin Technical Debt Plugin Updating PHPCI Vanilla Installation on OS X 10.10 Yosemite with OS X Server 4 Vanilla Mac Mavericks Server Installation Guide XMPP notifications plugin custom plugins setup
5 Maintainers
Marco Vito Moscaritolo edited this page 2015-01-18 21:50:52 +01:00
Table of Contents

Maintainers help to keep the PHPCI project moving, they do this by helping to manage issues, merging pull requests, improving documentation and by contributing code to the project.

Want to be a maintainer? Email Dan at dan@block8.co.uk for more information.

The current team of maintainers are as follows:

Core Maintainers

  • Dan (@dancryer)
  • Steve (@meadsteve)

Maintainers

  • Mike (@mikebronner)
  • James (@jfi)
  • Tobias (@tvbeek)
  • Marco (@mavimo)

Guidelines for Maintainers

Commit Access

Maintainers, by definition, have commit access to the project and can commit changes on behalf of contributors. However, with the exception of the core maintainers, maintainers are not entitled to bypass the contribution / pull request process.

Merging Pull Requests

It is the responsibility of the maintainers to merge pull requests, but only where they meet the contribution guidelines and pass our merging checklist.

Once the checklist has been completed, the pull request can be merged following the guidelines in the following blog post: http://blog.spreedly.com/2014/06/24/merge-pull-request-considered-harmful/

The Checklist

Is the pull-request ready to be merged?

The maintainer should check that the author has fully completed the bug fix / feature / refactor before merging the pull request.

Has the author properly explained the intended purpose of their pull request, and detailed their changes?

Authors need to explain in clear, concise language, what their patch is intended to do. Where their implementation is large or in any way complex, the changes themselves should be documented at the code level.

Has the author provided documentation updates for any new or changed features?

The wiki should not be updated until the pull request is merged, but documentation updates should be detailed in the pull request itself.

Has the pull request passed PHPCI checks?

It goes without saying that the project master branch should always pass its own PHPCI tests. This means that the patch will need to be PSR-2 compliant, all classes and methods should have valid docblocks, and all tests should pass.

Have at least two maintainers approved this pull request?

At least two maintainers should approve every pull request before it is merged. If you are the second maintainer to review a pull request, pending your approval it can be merged. Otherwise, apply the "flag:ready-to-merge" label to the pull request and consider tagging another maintainer to follow you.