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

Latest commit

 

History

History
61 lines (37 loc) · 4.02 KB

CONTRIBUTING.adoc

File metadata and controls

61 lines (37 loc) · 4.02 KB
Raw

Contributing

The dj project is an OPENISH Open Source Project

What?

Individuals making significant and valuable contributions are given commit-access to a project to contribute as they see fit. A project is more like an open wiki than a standard guarded open source project.

Rules

There are a few basic ground-rules for contributors (including the maintainer(s) of the project):

  1. No --force pushes or modifying the master branch history in any way. If you need to rebase, ensure you do it in your own repo.

  2. If you send a bugfix pull request, please do it against the master branch, if it’s a feature pull request, please do it against the feature branch.

  3. All modifications must be made in a pull-request to solicit feedback from other contributors.

  4. A pull-request must not be merged until CI has finished successfully.

Merge Process

Merging pull requests once CI is successful:

  1. A PR needs to be reviewed and approved by project maintainers unless:

    • it does not alter any logic (e.g. comments, dependencies, docs), then it may be tagged insubstantial and merged by its author once CI is complete.

    • it is an urgent fix with no large change to logic, then it may be merged after a non-author contributor has approved the review once CI is complete.

  2. Once a PR is ready for review please add the pleasereview label. Generally PRs should sit with this label for 48 hours in order to garner feedback. It may be merged before if all relevant parties had a look at it.

  3. PRs that break the external API must be tagged with breaksapi, when it changes the SRML or consensus of running system with breaksconsensus

  4. No PR should be merged until all reviews' comments are addressed.

Reviewing pull requests:

When reviewing a pull request, the end-goal is to suggest useful changes to the author. Reviews should finish with approval unless there are issues that would result in:

  1. Buggy behavior.

  2. Undue maintenance burden.

  3. Breaking with house coding style.

  4. Pessimization (i.e. reduction of speed as measured in the projects benchmarks).

  5. Feature reduction (i.e. it removes some aspect of functionality that a significant minority of users rely on).

  6. Uselessness (i.e. it does not strictly add a feature or fix a known issue).

Reviews may not be used as an effective veto for a PR because:

  1. There exists a somewhat cleaner/better/faster way of accomplishing the same feature/fix.

  2. It does not fit well with some other contributors' longer-term vision for the project.

Helping out

We use labels to manage PRs and issues and communicate state of a PR. Please familiarize yourself with them. Furthermore we are organizing issues in milestones. Best way to get started is to a pick a ticket from the current milestone tagged easy or medium and get going or mentor and get in contact with the mentor offering their support on that larger task.

Releases

Declaring formal releases remains the prerogative of the project maintainer(s).

Changes to this arrangement

This is an experiment and feedback is welcome! This document may also be subject to pull-requests or changes by contributors where you believe you have something valuable to add or change.

Heritage

These contributing guidelines are modified from the "OPEN Open Source Project" guidelines for the Level project: https://github.com/Level/community/blob/master/CONTRIBUTING.md