|
|
# IEEE OPEN SOURCE MAINTAINERS MANUAL
|
|
|
|
|
|
The following manual provides requirements and expectations for all users of the IEEE Open Source Platform.
|
|
|
|
|
|
All users of the IEEE Platform are granted the right to be maintainers of projects within their own username namespace, which include personal projects and personal forks of projects. As such, whether you are acting as a maintainer on a personal project or you have been granted the role of maintainer or contributor to an Official IEEE Open Source Project, you must follow the rules, requirements, and expectations outlined in this manual.
|
|
|
|
|
|
The Maintainers Manual open source project is organized into requirements, recommendations, and examples. Requirements are primarily outlined in the following document. Recommendations consist of templates you can used as a basis to help you meet the requirements. And examples relate to good ideas and practices that may or may not tie into any requirements or expectations.
|
|
|
|
|
|
## Conduct
|
|
|
|
|
|
All participants of IEEE Open Source Projects are expected to demonstrate respect
|
|
|
and courtesy toward each other. All maintainers shall act in accordance with the
|
|
|
[IEEE Code of Conduct](https://www.ieee.org/about/ieee_code_of_conduct.pdf) and
|
|
|
encourage all other participants in the projects they maintain to do the same.
|
|
|
|
|
|
In addition, with regard to the following referenced section of the
|
|
|
IEEE Policies document, any given requirements or recommendation that applies
|
|
|
to an IEEE Member shall be understood to apply equally to an
|
|
|
IEEE Open Source Project Maintainer.
|
|
|
|
|
|
* Definitions of Bullying, Discrimination, Harassment, and Retaliation.
|
|
|
* IEEE Code of Ethics (§7.8)
|
|
|
* Civility Policy, nondiscrimination (§9.25)
|
|
|
* IEEE Policy Against Discrimination and Harassment (9.26)
|
|
|
|
|
|
|
|
|
## Organization of Projects and Materials
|
|
|
|
|
|
The IEEE Open Source Platform consists of the code and document
|
|
|
repositories, license repositories, communication forums, project
|
|
|
management systems, and related administrative and end-user tools
|
|
|
maintained by IEEE for the purpose of hosting Open Source projects
|
|
|
together with the associated governance mechanisms, support
|
|
|
mechanisms, and other services offered to participants, users, and
|
|
|
consumers of Open Source projects.
|
|
|
|
|
|
An open source project may organize material and conduct business
|
|
|
across various parts of the IEEE Open Source Platform.
|
|
|
|
|
|
An IEEE Open Source Project must provide a single URL that can be
|
|
|
considered as the official homepage of the project. For example, this
|
|
|
could be the link to a project page on <https://opensource.ieee.org>.
|
|
|
|
|
|
### Homepage
|
|
|
|
|
|
On the IEEE Open Source Project Homepage, the following information must be provided (e.g., in a repo's READEME.md file) the following information:
|
|
|
|
|
|
* Project name
|
|
|
* Any important status concerns prominently displayed (e.g., a notice that it is unmaintained or archived, etc)
|
|
|
* A short description of how the project is organized
|
|
|
* Project license and links to appropriate CLAs
|
|
|
* How to contribute (such as a link to a CONTRIBUTING file)
|
|
|
* Project leadership
|
|
|
|
|
|
### Repository
|
|
|
|
|
|
Each open source project area that makes use of a git repository shall have the following files in any
|
|
|
|
|
|
* README - Project name, short description, license and CLA info,
|
|
|
* LICENSE - The official license of the project
|
|
|
* NOTICES - Any additional appropriate legal notices that must be included
|
|
|
* AUTHORS - A list of copyright holders
|
|
|
* CONTRIBUTORS - A list of contributors
|
|
|
* CONTRIBUTING (Governance and Code-of-Conduct) - Rules for contributing, may be split into a separate GOVERNANCE document
|
|
|
|
|
|
### Appropriate legal notices
|
|
|
|
|
|
Following best practices, files should contain a copyright and license notice.
|
|
|
|
|
|
## Responsibilities of Maintainers and Committers
|
|
|
|
|
|
A maintainer of an IEEE Open Source Project shall have the following
|
|
|
responsibilities:
|
|
|
|
|
|
* Ensuring, according to this manual, that all appropriate files,
|
|
|
documentation, and notices are in place for their Project on the
|
|
|
IEEE Open Source Platform.
|
|
|
|
|
|
* Adhering to the governance rules established by the project IEEE Open Source Project
|
|
|
|
|
|
* Responding to communication and notifications on the IEEE Open
|
|
|
Source Platform in a timely manner, as well as communication and
|
|
|
requests from the IEEE Open Source Lead, and the Open Source
|
|
|
Community Manager either through the platform or via another
|
|
|
communications channel.
|
|
|
|
|
|
## Stepping Down
|
|
|
|
|
|
If you’re the maintainer of an IEEE Open Source Project and you have decided
|
|
|
to step-down, please inform the IEEE Staff by either sending an email to
|
|
|
contrib@ieee.org stating the name of the project and the date you are planning
|
|
|
to step down, and any suggestion or information you may have as to who should
|
|
|
become the new maintainer. The appointment of a new maintainer needs the
|
|
|
approval of Leader(s) of the project.
|
|
|
|
|
|
## Security and Critical vulnerabilities
|
|
|
|
|
|
If a project's lead or maintainer, the Open Source Community Manager, or the Open Source Committee decide that a given project on the IEEE Open Source Platform needs to follow a security process for handling security reports and CVEs, then the requirements provided in [SECURITY/README.md](SECURITY/README.md) shall be followed and the creation of a SECURITY.md file shall be provided in the top-most level of your project's repository directory structure. A recommended [SECURITY.md](SECURITY/SECURITY.md) file has been provided for you.
|
|
|
|
|
|
If it is not determined that your project requires a formal security reporting process, then by default, a security bug can be treated as any other issue or bug filed against your project.
|
|
|
|
|
|
## Communication
|
|
|
|
|
|
## Naming, Branding, Trademark, and Tradename
|
|
|
|
|
|
IEEE Policy on Trademark applies to IEEE Open Source Projects. Please direct all questions or concerns to the IEEE Open Source Community Manager.
|
|
|
|
|
|
## Archiving
|
|
|
|
|
|
* How and when to move a project to an archived project
|
|
|
|
|
|
## Version
|
|
|
|
|
|
Information for IEEE Open Source Project maintainers. DRAFT
|
|
|
|
|
|
Copyright 2019, The Maintainers Manual AUTHORS (see AUTHORS file)
|
|
|
|
|
|
The IEEE Open Source Maintainers Manual is licensed to you under the
|
|
|
terms of the Apache License, Version 2.0. You may obtain a copy of the
|
|
|
License at
|
|
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
|
Unless required by applicable law or agreed to in writing, software
|
|
|
distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
|
implied. See the License for the specific language governing
|
|
|
permissions and limitations under the License.
|
|
|
|
|
|
|
|
|
## About This Document
|
|
|
|
|
|
***In accordance with the Open Source Committee Operations Manual, all
|
|
|
IEEE Open Source Project Maintainers shall follow the requirements set
|
|
|
forth.***
|
|
|
|
|
|
This manual contains guidelines, advice, and requirements of interest
|
|
|
to anyone contributing to or participating in an IEEE Open Source
|
|
|
Project.
|
|
|
|
|
|
We welcome your help in improving this manual. You can file an issue
|
|
|
or become a contributor (see CONTRIBUTE) to this open source project,
|
|
|
which is located at <https://opensource.ieee.org/oscom/maintain>.
|
|
|
|
|
|
All maintainers of IEEE Open Source Projects will be notified when new
|
|
|
official releases of this manual are released. A version history of all changes
|
|
|
between official releases of this document within the repository on the open
|
|
|
source project.
|
|
|
|
|
|
## Getting Help
|
|
|
{: .gitlab-red}
|
|
|
|
|
|
- Contact IEEE Open Source Community Manager
|
|
|
- Alternative contact (e.g., what they need to make a complaint about the OSCM).
|
|
|
|
|
|
|
|
|
|