-
Notifications
You must be signed in to change notification settings - Fork 227
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.
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
Updated contribution guidelines with more explicit process for becomi… #723
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
…ng a committer and publishing a release
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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. | ||
- *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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
There was a problem hiding this comment.
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.