Contributing to the Plone Intranet Project

Description

How to develop and submit code for the Plone Intranet Project.

Reaching the Plone Intranet team

To reach the Plone Intranet development team for any questions please contact

Note

If you’re a Plone Intranet developer but not on the developer list, please subscribe at https://groups.io/org/groupsio/ploneintranet-dev

Open Source License

This package is Copyright (c) Plone Foundation.

Any contribution to this package implies consent and intent to irrevocably transfer all copyrights on the code you contribute, to the Plone Foundation, under the condition that the code remains under a OSI-approved license.

To contribute, you need to have signed a Plone Foundation contributor agreement. If you’re listed on Github as a member of the Plone organization, you already signed.

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 as published by the Free Software Foundation.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

Definition of Done

In order for a pull request to be accepted the following development and style guidelines must be adhered to:

  • The continuous integration build must be passing
  • Any contributed code, must have 100% test coverage
  • Every contributed python function or method should have a test
  • Code that handles user input, must have unicode tests
  • Every UI form must have an associated robot test
  • Without exception, all contributed code must adhere to PEP8
  • All contributed code must have docstrings
  • All contributed APIs must have full Sphinx style docstrings
    • No commits directly on master - the master branch is protected
    • Pull requests must be reviewed by at least one other developer working on the project
    • Assign pull requests to another developer so they get notified, and chase them to review it. Stagnant pull requests become a lot harder to merge later.
  • Keep the documentation up to date
  • Every pull request should be related to an issue. A file in the news folder matching the pattern NNNN.type should be added containing a description of what the PR does. NNNN is the issue number, type can be any of added, changed, fixed, technical, updated. Pick the one that best suits your pull request.
  • Don’t commit commented-out code. We have version control, if you want to add code back later.

See Git workflow for an overview of our Git workflow.