From 6f23b5a88beb2b1a8079df8f03dff1caff477f64 Mon Sep 17 00:00:00 2001 From: Joshua Gay Date: Wed, 17 Jun 2020 15:26:09 -0400 Subject: [PATCH 1/5] Add new file --- content/CONTRIBUTING_example.md | 112 ++++++++++++++++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 content/CONTRIBUTING_example.md diff --git a/content/CONTRIBUTING_example.md b/content/CONTRIBUTING_example.md new file mode 100644 index 0000000..9a217e8 --- /dev/null +++ b/content/CONTRIBUTING_example.md @@ -0,0 +1,112 @@ + +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 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/)** + + +## 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 GOVERNANCE.md 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 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) -- GitLab From ac29a3ec4a48d78769a45e6ebedb513e81464aaf Mon Sep 17 00:00:00 2001 From: Joshua Gay Date: Wed, 17 Jun 2020 16:37:27 -0400 Subject: [PATCH 2/5] Fixed formatting on sample governance and procedures text blocks. --- content/CONTRIBUTING_example.md | 100 +++++++++++++++++++++----------- 1 file changed, 67 insertions(+), 33 deletions(-) diff --git a/content/CONTRIBUTING_example.md b/content/CONTRIBUTING_example.md index 9a217e8..2c39226 100644 --- a/content/CONTRIBUTING_example.md +++ b/content/CONTRIBUTING_example.md @@ -1,4 +1,3 @@ - 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: . -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. -- GitLab From 26f1b40914850414a5498de813b7ae5c53049a07 Mon Sep 17 00:00:00 2001 From: Joshua Gay Date: Wed, 17 Jun 2020 16:44:46 -0400 Subject: [PATCH 3/5] Fixes formatting and minor edits on CONTRIBUTING_example.md --- content/CONTRIBUTING_example.md | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/content/CONTRIBUTING_example.md b/content/CONTRIBUTING_example.md index 2c39226..cc88d7b 100644 --- a/content/CONTRIBUTING_example.md +++ b/content/CONTRIBUTING_example.md @@ -34,14 +34,16 @@ We greatly appreciate it if your merge request met the following criteria 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 +2. 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) +3. Write any appropriate continuous integration tests. +4. Push the commit(s) to your working branch in your fork. + - Squash commits into a small number of logically organized commits, keeping the commit history intact on shared branches + - please try to have fewer than 15 commit messages per merge request +5. 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 descriptoin should give the reason for the change + - use complete URLs to issues and other MR, milestone, etc + - include the complete path when referencing files within this repository (no URL required) ## Merge request acceptance criteria @@ -49,7 +51,7 @@ Your merge request needs at least 1 approval, but depending on your change you m ### Commit messages guidelines -Please follow Chris Beams seven rules for writing a good commit messages: +Please follow Chris Beam's 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 @@ -59,12 +61,13 @@ Please follow Chris Beams seven rules for writing a good commit messages: > 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: +For examples and additional explanation of these seven rules, please read Chris Beam's blog post: . **In addition, we ask that you also:** -* Use full urls to issues and merge requests (no short references, please) +* Use full urls to issues and merge requests (no short references, please) +* include the complete path when referencing files in your commit message body * Do not inlcude emoji in commit messages ## FIXME: Communicating with us -- GitLab From 407c4e488504d315badef3413f2b3759052d642f Mon Sep 17 00:00:00 2001 From: Joshua Gay Date: Mon, 12 Oct 2020 12:40:01 -0400 Subject: [PATCH 4/5] Adds simple readme file example --- content/README_simple.md | 71 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 content/README_simple.md diff --git a/content/README_simple.md b/content/README_simple.md new file mode 100644 index 0000000..7e7e18b --- /dev/null +++ b/content/README_simple.md @@ -0,0 +1,71 @@ + +The following README file template provides a simple way to comply with our basic governance document for an individual-run project. +The portions of this document that pertain to governance are the following sections: + +* Security +* Contributing +* Leadership +* License + +The remaining sections provide an outline with the common elements of README file. + + +## Project Name + +Succinctly state what this project does. + +## Background + +You can put a bit more of an elevator pitch here. Depending on the nature of you project you could then + +```javascript + +## - Provide a code snippet showing how to use your project +## - Provide a demo via animated gif or screenshot + +alert( 'Hello, world!' ); +``` + +## Run + +Explain how to deploy, configure, install, and/or run your project, and/or show how to use it. + +## Security + +If your project is of a nature that security flaws may create vulnerabilities for your users, then you should consider +inserting the IEEE SA Open SECURITY policy provided in the OSCom Maintainers Manual. + +## Contribute + +### CLA + +All contributors to this project must submit (or previously submitted) a valid and applicable +[Contributor License Agreement](https://opensource.ieee.org/community/cla). + +### Issue + +We request that you follow the GitLab workflow of filing an issue or commenting/contributing to an existing issue. + +### Fork and Merge + +Once you have submitted an issue, if you wish to make a contribution to this project, please: + +1. Fork the project into your personal userspace +2. Create a temporary branch (ideally with a similar subject line as the issue) +3. Develop your code trying to keep it to five or fewer commits (you can merge or squash excessive comments) +4. Create a merge request + +## Leadership + +Project lead and maintainer: User Name + +## License + +Copyright 2020 Project Name Authors + +See the LICENSE file distributed with this work for copyright and +licensing information, the AUTHORS file for a list of copyright +holders, and the CONTRIBUTORS file for the list of contributors. + +SPDX-License-Identifier: BSD-3-Clause + -- GitLab From 3cb4cb5cc695a3b955abaf11fc4254fd230e1447 Mon Sep 17 00:00:00 2001 From: Suzanne Merten Date: Tue, 10 Jan 2023 18:04:12 +0000 Subject: [PATCH 5/5] Update content/CONTRIBUTING_example.md --- content/CONTRIBUTING_example.md | 74 ++++++++++++++++----------------- 1 file changed, 37 insertions(+), 37 deletions(-) diff --git a/content/CONTRIBUTING_example.md b/content/CONTRIBUTING_example.md index cc88d7b..0e0057b 100644 --- a/content/CONTRIBUTING_example.md +++ b/content/CONTRIBUTING_example.md @@ -1,6 +1,6 @@ -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. +Please update any line that begins with the phrase FIXME and ensure that the requirements and criteria are acceptable and are 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 +# Contributor Workflow We welcome contributions from everyone and appreciate your consideration in helping us to improve our code, tests, and documentation. @@ -22,53 +22,53 @@ please consider including any mockups or screenshots if possible. ## Merge request criteria -We greatly appreciate it if your merge request met the following 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 +1. Your merge request should be 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 contribution in and of itself even 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) -2. 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. Fork our project into your personal namespace (or group). +2. 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). 3. Write any appropriate continuous integration tests. 4. Push the commit(s) to your working branch in your fork. - - Squash commits into a small number of logically organized commits, keeping the commit history intact on shared branches + - squash commits into a small number of logically organized commits, keeping the commit history intact on shared branches - please try to have fewer than 15 commit messages per merge request -5. Submit a merge request (MR) to our projects default branch +5. 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 change - - use complete URLs to issues and other MR, milestone, etc - - include the complete path when referencing files within this repository (no URL required) + - merge request descriptions should give the reason for the change + - use complete URLs to issues and other MR, milestone, etc. + - include the complete path when referencing files within this repository (no URL required). ## 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). +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 approval from multiple maintainers and our project lead(s). ### Commit messages guidelines -Please follow Chris Beam's seven rules for writing a good commit messages: +Please follow Chris Beam's seven rules for writing a good commit message: -> 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 +> 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 of these seven rules, please read Chris Beam's blog post: . **In addition, we ask that you also:** -* Use full urls to issues and merge requests (no short references, please) -* include the complete path when referencing files in your commit message body -* Do not inlcude emoji in commit messages +* Use full urls to issues and merge requests (no short references, please). +* Include the complete path when referencing files in your commit message body. +* Do not inlcude emoji in commit messages. ## FIXME: Communicating with us @@ -81,7 +81,7 @@ 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 +* Provide a brief explanation of your release workflow. Example below: > Release Workflow: > * We cycle through three milestones: current, next, and future. @@ -110,14 +110,14 @@ If you have a GOVERNANCE.md file or sufficient info in the README file then you > > 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) +> 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 should 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 +> * 70% of leadership must be present in a meeting for a vote to occur or a vote by email ballot is initiated. +> * Email ballots can have 10, 20, or 30 day periods. +> * Meetings follow Robert's 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. @@ -126,8 +126,8 @@ If you have a GOVERNANCE.md file or sufficient info in the README file then you > **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 +> * 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** @@ -138,12 +138,12 @@ If you have a GOVERNANCE.md file or sufficient info in the README file then you > > 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 +> When a vote is scheduled, we will update the issue with any appropriate due date information 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 +> 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 +> 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. +> 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. -- GitLab