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

Commit ac29a3ec authored by Joshua Gay's avatar Joshua Gay 🙀
Browse files

Fixed formatting on sample governance and procedures text blocks.

parent 6f23b5a8
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
......@@ -10,7 +9,7 @@ us to improve our code, tests, and documentation.
Please note that for any contribution to be accepted to this project, **you must have already submitted an appropriate CLA to oscontrib@ieee.org and have recieved from IEEE staff a CLA number.
FIXME: **Link to appropriate CLA project under [CLA group](the https://opensource.ieee.org/community/cla/)**
FIXME: **Link to appropriate CLA project under the group [community/CLA](https://opensource.ieee.org/community/cla/)**
## Milestones, issue boards, and labels
......@@ -63,10 +62,10 @@ Please follow Chris Beams seven rules for writing a good commit messages:
For examples and additional explanation please read Chris's article:
<https://chris.beams.io/posts/git-commit/>.
In addition, we ask that you also
**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
* Use full urls to issues and merge requests (no short references, please)
* Do not inlcude emoji in commit messages
## FIXME: Communicating with us
......@@ -80,33 +79,68 @@ If you have a GOVERNANCE.md file or sufficient info in the README file then you
* 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 GOVERNANCE.md policy document will be established with the guidance and support of the IEEE SA Open Community Manager.
> 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 about releases
> Project management and approvals process:
>
> Minor releases and patches
> * A lead and at least two maintainers must approve an issue being moved from future to next.
> * Merge requests associated with issues in *current* only need one approver to get merged.
> * Two approvers are needed to move an issue to put into *current* milestone.
>
> Major releases
>
> We strive for concensus amongst all leads and maintainers before tagging a new major release as such.
>
* Provide an explanation of how meetings and voting is done. Example below.
>
> All meetings are held on mattermost. We have one channel for public meetings and one for executive session.
> Video conferencing tools may be used in conjunction with mattermost if all participants can at least participate via a phone call.
>
> Calling a meeting
>
> 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. It is required that such a meeting sould happen in a timely fashion (e.g., ideally within 30 days but no more than 90 days)
>
>
> Quorum and protocols
>
> * 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
> * Meetings follow Roberts Rules of Order and voting uses the Condorcet method
>
> Modifying project policies
> * If the policies outlined in this document are found to be insufficient, then a more formal GOVERNANCE.md 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 opensource@ieee.org 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)
> **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
>
> *Right of appeal**
>
> You have the right to appeal the process; we ask that you email opensource@ieee.org stating you wish to the IEEE SA Open Source Community manager to review that the process was followed properly and fairly.
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