-
Notifications
You must be signed in to change notification settings - Fork 494
Development Process Policy
The repository has the following access teams:
Contributors have pull access to the repository. Since the repository is public, everyone falls into this group.
Maintainers have the same permissions as Contributors, but can also push to the repository.
Owners have the same permissions as Maintainers, and have administer access to the repository settings including adding and removing team members.
The following rules describe access and responsibilities: Individuals with Maintainer access must be employees or stakeholders, which can be active members of the community, to ensure their incentives are aligned with the success of the project. Maintainers are responsible for processing pull requests. Each pull request must first be code reviewed. There must be no “blind merges” of submitted branches. Maintainer access should not be given lightly, since contributors can always submit pull requests and having an abundance of maintainers increases the attack surface.
New contributors should not be given maintainer access since it takes experience with the project to make informed decisions in best interest of the project.
Additional maintainer members should only be added when the current number of maintainers is insufficient to efficiently process the volume of pull requests, when taking into account a margin for members going on vacation or being otherwise unavailable.
The developer training process for gaining maintainer access shall include a reasonable time spent performing code reviews on other people’s pull requests, under supervision by an existing maintainer.
Inspired by git flow
The develop branch holds work in progress. The master branch holds the latest official release. The release branch holds official releases and release candidates. When a new release is prepared, it appears in the release branch. That way the code and features for the next release can be frozen. It also gives opportunity for additional testing and will give stakeholders some lead time before the appearance of a new version.
When preparing a new release, the set of change commits is chosen from the develop branch and merged to the release branch. This becomes the proposed release.
The proposed release must pass all tests and can optionally be rolled out to a staging environment for QA. After a proposed release passes tests and QA, the commit log must be signed off by another maintainer. Releases may not be merged without being inspected by at least one other maintainer.
When the release is signed off and ready to be pushed to production, the release branch may be merged to master.
A release includes the following:
- Push the release to production
- Update github with release: https://github.com/ripple/ripple-client/releases
- Update wiki with release if applicable: https://ripple.com/wiki/Ripple_Client_Release_Notes
- Update npm release if applicable
- Hotfixes should go into a hotfix branch, which is branched off of master. A hotfix is an update to fix a very specific issue, often a pressing issue. Not necessarily publicly released or announced.
Pull request titles should be a summary of the changes being made Every pull request needs to be prefixed (e.g. [FEATURE]) Features will need sign-off from at least two reviewers before getting merged. Bugs need at least one. This is part of preparing for continuous integration set-up.
Reviewers need to sign off on a pull request by commenting with the message “LGTM” (Looks Good To Me). By standardizing the response we can have automated tools verify the current status of the pull request to the process.
The sign-off needs to happen after the last commit that was added to the pull request.
Minimum of 2 reviewers for feature Minimum of 1 reviewer for fix/task/doc/test
The code submission policy applies to all commits made a repository, regardless of author. Ideas from the BTCD Code Contribution Guidelines.
All code which is submitted will need to be reviewed before inclusion into the master branches. This process is performed by the project maintainers and usually other committers who are interested in the area you are working in as well.
Pull requests containing UI changes should include before/after screenshots in a pull request message.