Skip to content
This repository has been archived by the owner on Jul 27, 2022. It is now read-only.

Latest commit

 

History

History
68 lines (57 loc) · 4.05 KB

CONTRIBUTING.md

File metadata and controls

68 lines (57 loc) · 4.05 KB
Raw

Contributing to Joinup

Before you start

  • You're thinking of setting up your own code repository using the Joinup codebase?
  • You are about to develop a big feature on top of this codebase?
  • You're having trouble installing this project?
  • If you want to report an issue?

Use the Github issue queue to get in touch! We'd like to hear about your plans.

Legal

By submitting a pull request to the Joinup repository, you implicitly accept the conditions in the Joinup Individual Contributor Assignment Agreement as well as the code of conduct.

The Joinup codebase is released under the European Union Public Licence (EUPL).

How to contribute

Contribution to Joinup is similar to most other projects on GitHub: We use the fork and pull model, which means that everyone whom wants to contribute, can do so through a pull request from a fork of Joinup towards the Joinup repository. More information on pull requests is available on the 'using pull request' page.

We are however not obligated to use your contribution as part of Joinup and may decide to include any contribution we consider appropriate.

Code quality

We try to keep the quality of Joinup as high as possible, and therefore a few measures are put in place:

  • Adherence of the drupal coding standards is verified on each commit. (Please note that the coding standards can change in the future).
  • Functional tests (Behat) are ran on each commit to avoid the introduction of regression.

You can check our current test scenarios here.

If you plan to make contributions to the Joinup codebase, we kindly ask you to run the coding standards checks, as well as the Behat test suite before making a pull request. Also make sure you add test coverage for the functionality covered in the pull request.

Workflow

In order to get a contribution accepted in Joinup, follow this procedure:

  1. fork: Most contributions are forked from the develop branch where the main development takes place. However if an issue is highly critical and needs to be urgently put into production it should be forked from the master branch so it can be deployed as a hotfix.
  2. develop: Make sure the individual commits are well described and scoped. It is allowed to rebase feature branches to clean up the history. The pull request should only contain changes that are strictly necessary to complete the task on hand. It's fine to include small fixes in related code even if it is not strictly in scope, such as fixing typos, updating documentation and removing unused variables and use statements. The reviewer will have the right to reject any of these small fixes though if they are not immediately clear.
  3. qa: When development on the pull request is ready the code needs to be reviewed by the Joinup development team. The functionality offered in the PR should be covered by tests, and obviously all existing tests should pass. The development team regularly checks the open pull requests and will pick up tickets to be reviewed. Note that this might take some time since the work is organized in 2-weekly sprints. To avoid any confusion about the state of a PR feel free to post a comment mentioning that the PR is ready to be reviewed.
  4. uat: Once a PR has been approved by the development team it will be merged into the UAT-ready branch. A user acceptance test will be performed by the Joinup functional team which has the final decision whether the functionality will be accepted in Joinup.
  5. merge: Only after the functional team approves the PR it will be merged into the main branch by one of the developers.
  6. deploy: At the end of every 2-weekly sprint the develop branch will be merged into the master branch and a new release will be tagged. This release will then be deployed into production.