|     IEEE Xplore Digital Library     |     IEEE Standards     |     IEEE Spectrum     |     More Sites

Commit 6f23b5a8 authored by Joshua Gay's avatar Joshua Gay 🙀
Browse files

Add new file

parent 0c4622ff
Please update any line that begins with the phrase FIXME and ensure that the requirements and criteria are acceptalbe and ae able to be supported by your project before using this template. You are welcome to adapt this template to meet your needs or use it as is.
# Contributor workflow
We welcome contributions from everyone and appreciate your consideration in helping
us to improve our code, tests, and documentation.
## Contributor License Agreement (CLA)
Please note that for any contribution to be accepted to this project, **you must have already submitted an appropriate CLA to and have recieved from IEEE staff a CLA number.
FIXME: **Link to appropriate CLA project under [CLA group](the**
## Milestones, issue boards, and labels
If you are looking to find a way to contribute to our project, please first look over our milestones and issue boards to see if
your feature or bug has already been labeled.
If you want to contribute a new feature or bug fix that is not already labeled, it is best to first create an issue and our team will triage it by possibly requesting that you provide additional information as well as labeling it appropriately. Please note that if there are UI updates or bugs identified,
please consider including any mockups or screenshots if possible.
## Merge request criteria
We greatly appreciate it if your merge request met the following criteria
1. Your merge request should associated with an issue that defines the bug or feature that your merge requests fixes or adds.
2. Your merge request should include a test or tests (please note that submitting tests that confirm a bug is a great contributoin in and of itself evne if you aren't able to provide a fix for a given bug!)
3. Your merge request should update any relevant or impacted documentation
4. Try to keep the amount of changes you make in a single merge request as small as possible
## Merge request workflow
Please use the following workflow when submitting merge requests:
1. Fork our project into your personal namespace (or group)
1. Create a feature branch in your fork (if possible include the title of the issue or the issue number that the merge request corresponds to)
1. Write any appropriate continuous integration tests.
1. Please squash commits into a small number of logically organized commits, keeping the commit history intact on shared branches
1. Push the commit(s) to your working branch in your fork.
1. Submit a merge request (MR) to our projects default branch
- merge request title should describe the change you wish to make
- merge request descriptoin should give the reason for the chnage
1. please try to have fewer than 15 commit messages per merge request
## Merge request acceptance criteria
Your merge request needs at least 1 approval, but depending on your change you might need additional approvals. Merge requests that fix a regression are usually accepted quickly and usually only require a single approval, whereas a new feature may require approver from multiple maintainers and our project lead(s).
### Commit messages guidelines
Please follow Chris Beams seven rules for writing a good commit messages:
> 1. Separate subject from body with a blank line
> 2. Limit the subject line to 50 characters
> 3. Capitalize the subject line
> 4. Do not end the subject line with a period
> 5. Use the imperative mood in the subject line
> 6. Wrap the body at 72 characters
> 7. Use the body to explain what and why vs. how
For examples and additional explanation please read Chris's article:
In addition, we ask that you also
- Use full urls to issues and merge requests (no short references, please)
- Do not inlcude emoji in commit messages
## FIXME: Communicating with us
Add information about how best to communicate with your project and/or community including email addresses, mattermost channels, recurring meetings, etc. Or if you prefer communication be done through issues and merge requests, state that.
## FIXME: Project governance and new maintainer process
If you have a file or sufficient info in the README file then you can either remove this section or link to the appropriate file.
* List of project lead(s) with any affiliations that should be disclosed
* List of project maintainers (including any affiliations), and if appropriate, organized to provide what area of work a given maintainer is in charge of (e.g. documentation, release, devops/testing, etc).
* Provide a brief explanation of your release workflow. Example below
* Release Workflow:
* We cycle through three milestones: current, next, and future.
* The current release milestone is for bug fixes and regressions and should never result in new requirements or dependencies being added.
* We use semvar for version numbering with release candidate versions (RC) preceding any major or minor release
* Any maintainer can add tags although what becomes a high priority tag must be approved by the project lead(s)
* Provide a brief explanation of how decisions are made. Here is a short example:
* A lead and at least two maintainers must approve an issue being moved from future to next;
* Merge requests that associated with issues in *current* only need one approver to get merged however two approvers are needed to move an issue into the *current* milestone
* we strive for concensus amongst all leads and maintainers before tagging a new major release as such.
* Any maintainer may call for a meeting and a vote on any matter pertaining to disagreements on major and minor releases or the addition or removal of a maintainer
* 70% of leadership must be present in a meeitng for a vote to occur or an vote by email ballot is initiated; email ballots can have 10, 20, or 30 day periods
* We follow Roberts Rules of Order in our meetings and voting uses the Condorcet method
* If the policies outlined in this document are found to be insufficient, then a more formal policy document will be established with the guidance and support of the IEEE SA Open Community Manager.
* Explain criteria and process for how one can become a project maintainer. Here is an example process:
* **Requirements for becoming a new maintainer (preconditions)**
* Candidates must agree to adhere to all applicable project and IEEE policy
* You must have a valid and appropraite CLA on file with the IEEE SA
* We do not allow for more than two maintainers to be from a single company or organization and strongly take into consideration any conflicts of interest amongst our candidates.
* **Process for becoming a new maintainer**
* Please create a new issue that you mark as confidential.
* The Subject should be "New maintainer request: YOUR NAME" (substituting YOUR NAME with your preferred name). Inlcude in the body of your issue a a short background statement stating any affiliations or possible conflicts of interest.
* This issue will be our primary way of communicating with you throughout this process.
* Candidates must have sponsorship or endorsement of at least one other maintainer; such an endorsement will be noted on the gitlab issue you create.
* When a vote is schedule we will update the issue with any appropriate due date info and a comment
* You may recieve questions via this issue; please note that only maintainers and leads can access the issue as it is and will remain confidential
* Once a vote has been completed we will update the issue either welcoming you as a maintainer or rejecting you with or without explanation
* You have the right to appeal the process; we ask that you email stating you wish to the IEEE SA Open Source Community manager to review that the process was followed properly and fairly.
* The maintainer sponsoring you will submit your candidacy for a vote by the project leadership (all maintainers and leads)
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment