... | ... | @@ -49,9 +49,9 @@ Access the online version of this IEEE Open Source _Maintainers Manual_ here: |
|
|
|
|
|
Get **_help or report concerns_** with the Platform here:
|
|
|
|
|
|
< [https://opensource.ieee.org/help](https://opensource.ieee.org/help)>
|
|
|
* [https://opensource.ieee.org/help](https://opensource.ieee.org/help)
|
|
|
|
|
|
< [https://opensource.ieee.org/help/user/project/operations/error_tracking.html](https://opensource.ieee.org/help/user/project/operations/error_tracking.html)>
|
|
|
* [https://opensource.ieee.org/help/user/project/operations/error_tracking.html](https://opensource.ieee.org/help/user/project/operations/error_tracking.html)
|
|
|
|
|
|
**_Ethics and Compliance Helpline_**: Reports of violations, or concerns regarding potential violations, of IEEE Policies or the IEEE Code of Conduct can be filed anonymously through EthicsPoint:
|
|
|
|
... | ... | @@ -73,8 +73,6 @@ Project governance may be provided by a single individual or organization; by a |
|
|
|
|
|
Project governance policies and procedures addresses questions such as:
|
|
|
|
|
|
|
|
|
|
|
|
* Who is the Project Lead;
|
|
|
* How Maintainers and Committers are determined, added, removed, and authorized;
|
|
|
* Who may contribute to the project;
|
... | ... | @@ -84,14 +82,13 @@ Project governance policies and procedures addresses questions such as: |
|
|
|
|
|
Projects other than individual projects can determine how they are organized (e.g., into teams or sub-projects) and set their own policies, goals, plans, schedules, and means of communications with project participants. The IEEE Open Source Community Manager (“Community Manager”) will provide samples of governance policies and procedures that can be used or adapted by Open Source projects. The governance policies and procedures of an Official IEEE Open Source project are made publicly available.
|
|
|
|
|
|
|
|
|
### 2.2 Governance organizations and leaders
|
|
|
|
|
|
The IEEE SA Board of Governors (BOG) has assigned responsibility for policies and overall management of the Platform to its Open Source Committee (OSCom). This committee reviews and approves applications for Official IEEE Open Source projects to use the Platform. The work of OSCom is governed by the _[IEEE SA Open Source Committee Operations Manual](https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/other/OSCOM_Operations_Manual.pdf)_. Additional requirements for Maintainers of projects incorporated into IEEE standards are located in [Section 6.5](https://standards.ieee.org/about/policies/opman/sect6.html#6.5) of _IEEE SA Standards Board Operations Manual_.
|
|
|
The IEEE SA Board of Governors (BOG) has assigned responsibility for policies and overall management of the Platform to its Open Source Committee (OSCom). This committee reviews and approves applications for Official IEEE Open Source projects to use the Platform. The work of OSCom is governed by the [_IEEE SA Open Source Committee Operations Manual_](https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/other/OSCOM_Operations_Manual.pdf). Additional requirements for Maintainers of projects incorporated into IEEE standards are located in [Section 6.5](https://standards.ieee.org/about/policies/opman/sect6.html#6.5) of _IEEE SA Standards Board Operations Manual_.
|
|
|
|
|
|
Technical and administrative responsibility for use of the Platform is assigned to the Community Manager. In addition, the IEEE SA provides an Intellectual Property Rights Manager (“IPR Manager”), who is responsible for licensing and risk management, and other supporting staff. All of these staff, together with OSCom, are tasked with supporting users and are there to help as well as to fulfill their organizational and governance responsibilities.
|
|
|
|
|
|
The Community Manager ** __ ** is the primary point of contact for Project Leads and Maintainers. The Community Manager oversees the operation of the Platform and provides support on access to the Platform, tools that are part of the Platform or that can be used with it, release requirements and management, security, configuration management, and testing. If you are a Project Lead or are assigned as an IEEE Open Source Project Representative, you have a responsibility to respond to requests from the Community Manager in a timely manner. Project Leads and Maintainers should contact the Community Manager if they have questions about governance or to report security concerns.
|
|
|
The Community Manager is the primary point of contact for Project Leads and Maintainers. The Community Manager oversees the operation of the Platform and provides support on access to the Platform, tools that are part of the Platform or that can be used with it, release requirements and management, security, configuration management, and testing. If you are a Project Lead or are assigned as an IEEE Open Source Project Representative, you have a responsibility to respond to requests from the Community Manager in a timely manner. Project Leads and Maintainers should contact the Community Manager if they have questions about governance or to report security concerns.
|
|
|
|
|
|
|
|
|
### 2.3 Open Source project roles and responsibilities
|
... | ... | @@ -100,8 +97,6 @@ Regardless of category, all Open Source projects have specific roles with define |
|
|
|
|
|
The primary roles for projects are the following:
|
|
|
|
|
|
|
|
|
|
|
|
* Project Lead
|
|
|
* Maintainer
|
|
|
* Committer
|
... | ... | @@ -118,8 +113,6 @@ Project Leads and Maintainers who can no longer carry out their responsibilities |
|
|
|
|
|
**_Responsibilities of Maintainers._** Maintainers have all the responsibilities and rights of Committers, plus the following responsibilities:
|
|
|
|
|
|
|
|
|
|
|
|
* Ensuring that all required files, documentation, and notices are in place for their project on the Platform in accordance with this manual;
|
|
|
* Administering the governance rules adopted by their project;
|
|
|
* Maintaining control of the baseline source, forks, and releases during active development;
|
... | ... | @@ -133,7 +126,7 @@ Project Leads and Maintainers who can no longer carry out their responsibilities |
|
|
|
|
|
**_Responsibilities of Users._** The IEEE Open Source Platform makes available digital work for which the human-readable source code is available for use, study, re-use, modification, enhancement, and re-distribution by Users. Users are responsible for observing the copyright and licensing information in each open source file.
|
|
|
|
|
|
**3 Account and group management**
|
|
|
## 3 Account and group management
|
|
|
|
|
|
|
|
|
### 3.1 Using the IEEE Open Source Platform
|
... | ... | @@ -159,8 +152,6 @@ To request a new Open Source project in the Platform, or to change a Project fro |
|
|
|
|
|
You will need to enter the following information:
|
|
|
|
|
|
|
|
|
|
|
|
* Project category;
|
|
|
* Project title;
|
|
|
* Project description (purpose);
|
... | ... | @@ -171,10 +162,7 @@ You will need to enter the following information: |
|
|
* A description of the relationship of the project to known Open Source;
|
|
|
* Project visibility (public, internal, or private--see section 1);
|
|
|
* If applicable, the associated PAR or IEEE standard(s);
|
|
|
* Agreement to adhere to the Terms of Use and selected CLA
|
|
|
|
|
|
[https://opensource.ieee.org/community/cla/terms-of-use/blob/master/terms-of-use.md](https://opensource.ieee.org/community/cla/terms-of-use/blob/master/terms-of-use.md)<span style="text-decoration:underline;"><span style="text-decoration:underline;">.</span>
|
|
|
|
|
|
* Agreement to adhere to the [Terms of Use](https://opensource.ieee.org/community/cla/terms-of-use/blob/master/terms-of-use.md) and selected CLA
|
|
|
|
|
|
The project will be set up once reviewed and approved. Individual and Group projects are approved by the Community Manager. IEEE Official Projects are also reviewed and approved by OSCom.
|
|
|
|
... | ... | @@ -182,8 +170,6 @@ All features are enabled for blank projects or when importing from Platform temp |
|
|
|
|
|
On startup, your project will have the following files in its git Repository:
|
|
|
|
|
|
|
|
|
|
|
|
* README - Project name, short description, license and CLA type, and other information taken from your application for the project as approved,
|
|
|
* LICENSE - The official license of the project
|
|
|
* NOTICES - Any additional appropriate legal notices that shall be included
|
... | ... | @@ -208,11 +194,9 @@ More help on getting started with a project, available elements, and using templ |
|
|
|
|
|
## 4 Running a project
|
|
|
|
|
|
This section includes rules and advice for the Project Lead and Maintainer who are running an active project. For most projects on the Platform, this involves the use of Git, a distributed version control system used to coordinate collaborative work among project members. Comprehensive guidance for Maintainers learning and using Git can be found in the [Pro Git book available here](https://git-scm.com/book/en/v2):
|
|
|
|
|
|
[https://git-scm.com/book/en/v2](https://git-scm.com/book/en/v2)
|
|
|
This section includes rules and advice for the Project Lead and Maintainer who are running an active project. For most projects on the Platform, this involves the use of Git, a distributed version control system used to coordinate collaborative work among project members. Comprehensive guidance for Maintainers learning and using Git can be found in the [Pro Git book](https://git-scm.com/book/en/v2).
|
|
|
|
|
|
For additional guidance, email the Community Manager at [contrib@ieee.org](mailto:contrib@ieee.org)<span style="text-decoration:underline;"> <span style="text-decoration:underline;"></span> or chat with us in our MatterMost channel.
|
|
|
For additional guidance, email the Community Manager at [contrib@ieee.org](mailto:contrib@ieee.org) or chat with us in our MatterMost channel.
|
|
|
|
|
|
|
|
|
### 4.1 Delegating responsibility and access control
|
... | ... | @@ -228,14 +212,12 @@ Branching and forking are two accepted development flows. Generally, established |
|
|
|
|
|
More explanations here:
|
|
|
|
|
|
[https://www.pluralsight.com/blog/software-development/the-definitive-guide-to-forks-and-branches-in-git ](https://www.pluralsight.com/blog/software-development/the-definitive-guide-to-forks-and-branches-in-git%20)
|
|
|
[https://www.pluralsight.com/blog/software-development/the-definitive-guide-to-forks-and-branches-in-git](https://www.pluralsight.com/blog/software-development/the-definitive-guide-to-forks-and-branches-in-git)
|
|
|
|
|
|
Projects can be set up to use automated continuous integration/continuous deployment (CI/CD). Consult the Community Manager for help with this.
|
|
|
|
|
|
Projects may choose to have Contributors sign off on specific contributions to indicate that due diligence or testing has been performed. Project governance documents should detail if approval is needed (and by whom) for committers merging the following:
|
|
|
|
|
|
|
|
|
|
|
|
* New executable open source code;
|
|
|
* Existing (third-party) open source code Contributions;
|
|
|
* Non-executable text documentation (such as comments, images, specifications, requirements, user stories, user assistance, readme files); or
|
... | ... | @@ -243,37 +225,28 @@ Projects may choose to have Contributors sign off on specific contributions to i |
|
|
|
|
|
More detailed information is here:
|
|
|
|
|
|
[https://git-scm.com/book/en/v2/Distributed-Git-Maintaining-a-Project](https://git-scm.com/book/en/v2/Distributed-Git-Maintaining-a-Project)
|
|
|
|
|
|
[https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project)
|
|
|
* [https://git-scm.com/book/en/v2/Distributed-Git-Maintaining-a-Project](https://git-scm.com/book/en/v2/Distributed-Git-Maintaining-a-Project)
|
|
|
* [https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project)
|
|
|
|
|
|
|
|
|
### 4.3 Licensing enforcement
|
|
|
|
|
|
The Maintainer is responsible for validation, scanning, and enforcement of CLAs (see Section 8 Licensing). This includes:
|
|
|
|
|
|
|
|
|
|
|
|
* Making sure that applicable licenses and legal notices are included in the project files, i.e. checking that the correct copyright and license notice has been added to each source code file as a LICENSE file or as text within the source code file;
|
|
|
* Adding required notices and disclaimers to your README file;
|
|
|
* Responding promptly to alerts of unlicensed material and removing or quarantining it; and
|
|
|
* Using the issue management system to update and close out reports of licensing issues.
|
|
|
|
|
|
|
|
|
### 4.4 Managing issues and problems
|
|
|
|
|
|
Maintainers are required to respond to issues that:
|
|
|
|
|
|
|
|
|
|
|
|
* Involve security;
|
|
|
* Pertain to compliance with applicable licenses, policies, or law;
|
|
|
* Were assigned to a Maintainer by the Community Manager.
|
|
|
|
|
|
Maintainers can create or respond to merge requests on their own but should create issues for merge requests that would require changes in policy, entail significant implementation effort, or otherwise have a significant effect on users. Creating these issues allows feedback to be gathered from contributors. More information on creating and managing issues is here:
|
|
|
|
|
|
[https://opensource.ieee.org/help/user/project/issues/index.md](https://opensource.ieee.org/help/user/project/issues/index.md)
|
|
|
|
|
|
Maintainers can create or respond to merge requests on their own but should create issues for merge requests that would require changes in policy, entail significant implementation effort, or otherwise have a significant effect on users. Creating these issues allows feedback to be gathered from contributors. More information on creating and managing issues is here: [https://opensource.ieee.org/help/user/project/issues/index.md](https://opensource.ieee.org/help/user/project/issues/index.md).
|
|
|
|
|
|
### 4.5 Peer reviewing
|
|
|
|
... | ... | @@ -283,7 +256,6 @@ Open Source projects intentionally build on previous development and the work pr |
|
|
|
|
|
Open Source peer reviews can be requested from the Community Manager or arranged by the project team. Platform peer reviewers may be selected from a pool of Open Source community members and include those with experience in software design, coding, and testing and, when feasible, subject matter experts (SMEs) with knowledge of the relevant IEEE technical area and current related software resources. Peer review may be enabled by collaboration with IEEE Societies and Special Interest Groups which are knowledgeable in specific technical areas (e.g. hardware design and testing, energy and power, antennas, photonics, medical devices).
|
|
|
|
|
|
|
|
|
### 4.6 Publicizing and representing your project and the IEEE
|
|
|
|
|
|
Publicity about IEEE Open Source projects, especially project releases or experiences using the Platform, is encouraged.
|
... | ... | @@ -309,28 +281,28 @@ A release package always includes a READ.ME file and a license file. |
|
|
|
|
|
We use semantic versioning [SemVer] for versioning.
|
|
|
|
|
|
[http://semver.org](http://semver.org)
|
|
|
* [http://semver.org](http://semver.org)
|
|
|
|
|
|
Official releases have a mirror copy archived in a private area. All previous Official releases remain in the Project archive.
|
|
|
|
|
|
More information on strategy for executing releases is here:
|
|
|
|
|
|
[https://docs.gitlab.com/ee/topics/gitlab_flow.html](https://docs.gitlab.com/ee/topics/gitlab_flow.html)
|
|
|
* [https://docs.gitlab.com/ee/topics/gitlab_flow.html](https://docs.gitlab.com/ee/topics/gitlab_flow.html)
|
|
|
|
|
|
|
|
|
## 6 Standards Considerations
|
|
|
|
|
|
In addition to being approved by OSCom, projects that are incorporated into IEEE standards shall follow additional rules designed to ensure that technical decisions are made in accordance with the principles of open, consensus standards development and are overseen by the committee that developed or is developing the standard. IEEE Open Source Standards projects have special considerations for project management, initiation, project review and release, and maintenance of the Open Source product that is part of an IEEE standard. These projects, and the resulting open source product (e.g., software and related information) are governed by the _IEEE SA Standards Board Bylaws_[ https://standards.ieee.org/about/policies/bylaws/index.html](https://standards.ieee.org/about/policies/bylaws/index.html)
|
|
|
|
|
|
and _IEEE SA Operations Manual_ section 6.5:[ ](about:blank)
|
|
|
and _IEEE SA Operations Manual_ section 6.5:
|
|
|
|
|
|
[https://standards.ieee.org/about/policies/opman/index.html](https://standards.ieee.org/about/policies/opman/index.html)
|
|
|
* [https://standards.ieee.org/about/policies/opman/index.html](https://standards.ieee.org/about/policies/opman/index.html)
|
|
|
|
|
|
as well as this IEEE Open Source _Maintainers Manual_.
|
|
|
|
|
|
The complete IEEE standards development process is explained here:
|
|
|
|
|
|
< [https://standards.ieee.org/develop/index.html](https://standards.ieee.org/develop/index.html)>
|
|
|
* [https://standards.ieee.org/develop/index.html](https://standards.ieee.org/develop/index.html)
|
|
|
|
|
|
|
|
|
### 6.1 Management responsibilities
|
... | ... | @@ -385,8 +357,6 @@ Open Source software artifacts associated with inactivated projects may be archi |
|
|
|
|
|
Projects may be terminated or deprecated and archived (inactivated) by the Community Manager if the project has:
|
|
|
|
|
|
|
|
|
|
|
|
* No sign of activity (logons by Project Lead, Maintainer, Committer, or Contributor) for 180 days.
|
|
|
* No identified Project Lead or Maintainer, or no response from the previous Project Lead and Maintainer, for 45 days.
|
|
|
|
... | ... | @@ -398,11 +368,8 @@ See Section 6.5 regarding inactivation of IEEE Open Source Standards projects. |
|
|
|
|
|
The following actions are required to retire a project:
|
|
|
|
|
|
|
|
|
|
|
|
* Update README file and CONTRIBUTING/GOVERNANCE files to state that the project is no longer actively maintained.
|
|
|
* Email the Community Manager at [contrib@ieee.org](mailto:contrib@ieee.org)<span style="text-decoration:underline;"> <span style="text-decoration:underline;"></span> to have the project archived
|
|
|
|
|
|
* Email the Community Manager at [contrib@ieee.org](mailto:contrib@ieee.org) to have the project archived
|
|
|
|
|
|
## 8: IEEE Policies and Licensing
|
|
|
|
... | ... | @@ -426,7 +393,7 @@ By participating as a Project Lead, Maintainer, or Contributor to an IEEE Open S |
|
|
* [IEEE Terms and Conditions](https://www.ieee.org/site-terms-conditions.html?WT.mc_id=hpf_terms&utm_source=hp&utm_campaign=hpf_terms&utm_medium=hpf&utm_term=terms%20conditions)
|
|
|
* [IEEE Nondiscrimination Policy](https://www.ieee.org/about/corporate/governance/p9-26.html%5D(https://www.ieee.org/about/corporate/governance/p9-26.html)
|
|
|
* [IEEE Principles of Business Conduct and Conflict of Interest](https://www.ieee.org/about/compliance/conflict-of-interest/index.html)
|
|
|
* IEEE Privacy Policy <https://www.ieee.org/security-privacy.html>
|
|
|
* [IEEE Privacy Policy](https://www.ieee.org/security-privacy.html)
|
|
|
* [Compliance Related IEEE Policies](https://www.ieee.org/content/dam/ieee-org/ieee/web/org/about/whatis/ieee_policies.pdf), including:
|
|
|
* Anti-Boycott Policy (§12.12)
|
|
|
* Anti-Bribery and Corruption Policy (§12.13)
|
... | ... | @@ -474,7 +441,6 @@ Each Maintainer and Committer is required to take steps to ensure that intellect |
|
|
For each contribution, the Committer and Maintainer shall check that:
|
|
|
|
|
|
|
|
|
|
|
|
1. That the name and email address of the Contributor(s) are accurately captured;
|
|
|
2. That the Contributor(s) have signed the IEEE Open Source Contributor License Agreement (CLA) and have a CLA number;
|
|
|
3. That the Contributor has signed-off the Contribution, indicating that they are in compliance;
|
... | ... | |