Express Gateway follows the contributing guidelines established by Express.JS and the Node Foundation.
The goal of this document is to create a contribution process that:
- Encourages new contributions.
- Encourages contributors to remain involved.
- Avoids unnecessary processes and bureaucracy whenever possible.
- Creates a transparent decision making process that makes it clear how contributors can be involved in decision making.
- A Contributor is any individual creating or commenting on an issue or pull request.
- A Committer is a subset of contributors who have been given write access to the repository.
- A TC (Technical Committee) is a group of committers representing the required technical expertise to resolve rare disputes.
Log an issue for any question or problem you might have. When in doubt, log an issue, and any additional policies about what to include will be provided in the responses. The only exception is security disclosures which should be sent privately.
Committers may direct you to another repository, ask for additional clarifications, and add appropriate metadata before the issue is addressed.
Please be courteous and respectful. Every participant is expected to follow the project's Code of Conduct.
When contributing to Express Gateway please consider the Express Gateway roadmap and community feedback for features. The Express Gateway roadmap is broken into three parts. This design enables features to be added with community feedback, transparency and ease based on the stage of consideration.
- FeatHub - a list of features that users can vote on so that the project maintainers can prioritize
- roadmap - all features and timeframes being considered, filtering from feature hub and other sources
- waffle board - the current backlog and next few sprints leading up to the next release of Express Gateway
The three parts are designed to filter signal from noise and reduce clutter commonly seen on other open source projects.
Any change to resources in this repository must be through pull requests. This applies to all changes to documentation, code, binary files, etc. Even long term committers and TC members must use pull requests.
A pull request should contain:
- a spec if applicable, e.g. a GitHub gist, public Google Doc, etc.
- tests
- docs (please open a separate pull request in the express-gateway.io repo and reference the pull request #)
Tests for Express Gateway can be found in the test directory.
Docs for Express Gateway are in the express-gateway.io repo under the docs directory.
No pull request can be merged without being reviewed. Pull request reviews can be requested by a specific contributor or group of contributors.
Please make sure that the build passes for your branch. Express Gateway currently uses CircleCI.
For non-trivial contributions, pull requests should sit for at least 36 hours to ensure that contributors in other timezones have time to review. Consideration should also be given to weekends and other holiday periods to ensure active committers all have reasonable time to become involved in the discussion and review process if they wish.
The default for each contribution is that it is accepted once no committer has an objection. During review committers may also request that a specific contributor who is most versed in a particular area gives a "LGTM" before the PR can be merged. Once all issues brought by committers are addressed and all reviews have been completed, the pull request can be landed by any committer.
In the case of an objection being raised in a pull request by another committer, all involved committers should seek to arrive at a consensus by way of addressing concerns being expressed by discussion, compromise on the proposed change, or withdrawal of the proposed change.
If a contribution is controversial and committers cannot agree about how to get it to land or if it should land then it should be escalated to the TC. TC members should regularly discuss pending contributions in order to find a resolution. It is expected that only a small minority of issues be brought to the TC for resolution and that discussion and compromise among committers be the default resolution mechanism.
All contributors who land a non-trivial contribution should be on-boarded in a timely manner, and added as a committer, and be given write access to the repository.
Committers are expected to follow this policy and continue to send pull requests, go through proper review, and have other committers merge their pull requests.
The TC uses a "consensus seeking" process for issues that are escalated to the TC. The group tries to find a resolution that has no open objections among TC members. If a consensus cannot be reached that has no objections then a majority wins vote is called. It is also expected that the majority of decisions made by the TC are via a consensus seeking process and that voting is only used as a last-resort.
Resolution may involve returning the issue to committers with suggestions on how to move forward towards a consensus. It is not expected that a meeting of the TC will resolve all issues on its agenda during that meeting and may prefer to continue the discussion happening among the committers.
Members can be added to the TC at any time. Any committer can nominate another committer to the TC and the TC uses its standard consensus seeking process to evaluate whether or not to add this new member. Members who do not participate consistently at the level of a majority of the other members are expected to resign.