Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Updated contribution guidelines with more explicit process for becomi… #723

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Updated contribution guidelines with more explicit process for becomi… #723

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 46 additions & 1 deletion CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,13 +6,58 @@ When submitting a pull request (PR), please use the following guidelines:
the same coding style as the code that you are modifying. If you are using
IntelliJ, you can import our code style settings xml:
[elide-intellij-codestyle.xml](https://github.com/yahoo/elide/raw/master/elide-intellij-codestyle.xml).
- Do add/update documentation appropriately for the change you are making.
- Do add/update documentation appropriately for the change you are making. Documentation for Elide is maintained in [another repo](https://github.com/yahoo/elide-doc).
- Bugfixes should include a unit test or integration test reproducing the issue.
- Do not use author tags/information in the code.
- Always include license header on each file your create. See [this example](https://github.com/yahoo/elide/blob/master/elide-core/src/main/java/com/yahoo/elide/Elide.java)
- Try to keep pull requests short and submit separate ones for unrelated
features, but feel free to combine simple bugfixes/tests into one pull request.
- Keep the number of commits small and combine commits for related changes.
Each commit should compile on its own and ideally pass tests.
- Update the [changelog](https://github.com/yahoo/elide/blob/master/changelog.md) with a description of the changes.
- Keep formatting changes in separate commits to make code reviews easier and
distinguish them from actual code changes.
- All code must receive at least one positive review from _another_ committer to be merged to master.

# Community

While anyone is free to open pull requests against the project, Elide has two defined roles:
- *Committers* - Are the gatekeepers of the repository. They approve pull requests and have write access to merge against master or other mainline branches. Committers also help set the direction for the project by deciding on major enhancements or design changes.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we detail a more complete process for committers and admins in this doc? Perhaps a doc solely related to that may make more sense.

Anyway, what I’m expecting is something outlining the primary communication channels for committees/admins to stay on the same page with design and project movement.

I imagine much of this conversation to take place in a public place, but formalizing a location may make it easier for everyone to stay in sync.

- *Admins* - Are responsible for publishing Elide releases. They are also responsible for maintaining the project's community process and webpage.

The current committer list includes:
| Name | Organization | Admin |
| ---------------- | ------------- |-------|
| Dennis McWherter | Amazon | X |
| Aaron Klish | Yahoo | X |
| William Cekan | Yahoo | X |
| Clay Reimann | Yahoo | X |
| Dan Chen | Yahoo | |
| Jon Kilroy | Yahoo | |

## Becoming A Committer

Committers are contributors who:
- Have demonstrated a good understanding of Elide through contribution of code, documentation, and forum discussion.
- Follow the [code of conduct](https://www.apache.org/foundation/policies/conduct.html) when communicating within the community.

New committers are either nominated by another committer or can request to become a committer. Nominated committers must have a net total of
at least three positive votes from other committers to gain committer status and be added to this page. Voting will be public and will take place in
the _general_ forum on Elide's slack.

# Releases

Releases are published manually from master by project Admins.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also outline the release process in detail. Technically, how one would go about it, that is.


When a new release is published, it is first published as a release candidate. The candidate will be available for up to 1 week for testing from the community before
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea of release candidates. That said, should we suggest a minimum time for non-critical (I.e. non-security related) releases to give the community time to consume it?

The way I’ve read this is that there is a maximum bake time of 1 week.

it is marked official. During that week, the official release can be blocked by a detailed github issue filed against the release candidate.
If the issue is considered significant by the project admins, the release is blocked until a new release candidate can be proposed.

Candidate releases will be announced in the _general_ forum of Elide's slack.

## Release Labels

Elide releases follow [semantic versioning](https://semver.org/).

Release candidates are marked by appending the semantic version with a hyphen (-), the text 'RC', and a number indicating the candidate number.
For example, 4.14.3-RC2 is the second release candidate for the 4.14.3 release.