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

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

Upload New File

parent edc717ce
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 articipants 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]( and
encourage all other partcipants 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, nondiscrimintation (§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 oranize 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
### Homepage
On the IEEE Open Source Project Homepage, the following information must be provided (e.g., in a repo's file) the following information:
* Project name
* Any important status concerns prominantly 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 separete 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
* 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 notificatoins 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
commuincations 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 stating the name of the project and the date you are planning
to step down, and any suggestion or infomration 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 seucity process for handling security reports and CVEs, then the requirements provided in [SECURITY/](SECURITY/ shall be followed and the creation of a file shall be provided in the top-most level of your project's repository directory structure. A recommended [](SECURITY/ 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
Informatoin 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
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
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
This manual contains guidelines, advice, and requirements of interest
to anyone contributing to or participating in an IEEE Open Source
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 <>.
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.
### Acknowledgements
Thanks go to the Free Software Foundation and the GNU Project for the
[**GNU Maintainers Manual**](;
and to Karl Fogel for (**Producing Open Source Software**, 2nd edition)[].
These works provided useful ideas that we have used in developing this manual.
## Getting Help
{: .gitlab-red}
- Contact IEEE Open Source Community Manager
- Alternative contact (e.g., what they need to make a complaint about the OSCM).
* Create <>
* Determine how we will obtain CVE numbers
We encourage you to use the template we have provided for you.
Below is our recommended security process which you may be required to
follow if your project has been deemed as needing a formal security
reporting process.
## Security process
All projects on the IEEE Open Source Platform that have been deemed as needing
a formal security reporting process are required to have a file
in the root directory of their project's repository and to follow the following
seucirty process (or an alternative security process approved by the
Open Source Committee and approved for use by your project).
1. Security vulnerabilities are reported to <>. Security reports are confidential.
2. The Open Source Community Manager will contact the *security
contact* listed by the Official IEEE Open Source Project and ensure
that the security vulnerability is reviewed to determine if it is
accepted or rejected. You may choose to list the maintainer that is
the appropraite security contact on your project (such as in your page) or you may provide the contact (or list of
contacts) to the Open Source Community Manager to maintain
3. The Open Source Community Manager will notify the reporter if their
report has been accepted or rejected
4. If a report is accepted the following protocol shall be followed:
a. The Open Source Community Manager will determine if a CVE number should be obtained, and if so, IEEE shall obtain a CVE number.
b. The project will patch the vulernability and stage a release and draft a short announcement that includes the CVE number, severity, and impact.
c. The Open Source Community Manager will review the release and
announcement and coordinate to schedule a date and time for
public releaes. At this time, your project may discuss with the
Open Source Community Manager any private disclosures you wish to
make in advance of the public disclosure, such as to the reporter
of the vulernability or to any identified stakeholders. The Open
Source Community Manager will only deny requests if there are any
suspicion that permitting such a request would violate IEEE
Policy or if the private disclosure would in effect be equivalent
of making a public disclosure.
d. The release shall be made as it normally would, but without
disclosing that it is patching a security vulnerability.
e. The release shall be timed so that a release announcement will be
sent out to immediately after the release. The announcement shall
go out to all relevant security announcement mailing lists as
well as any external security lists or portals the Open Source
Community Manager deems appropriate (e.g.,
5. If a report is accepted and this project is also an IEEE Standard
that incorporates an IEEE Open Source Project, then the additional
standards protocol will be followed as well.
a. If the project is incorporated through an undated/unversioned
reference, then the above protocol suffices with the caveat that
there may be additional mailing list or forums where the
announcement will be posted.
b. If the project is incorporated through a versioned reference,
then it must be determined if it is an errata or corrigenda. If
it is an errata, the above protocol shall be followed with the
announcement timed to coincide with the errata. If a corrigenda
is required, then the above protocol shall be followed and the
corrigenda process shall be followed after the announcement is
made, and additional notices shall be placed on apporpriate
places warning users about the issue.
* Create <>
* Determine how we will obtain CVE numbers
You may choose to adapt our standard template or to construct your own
security process documentation. In all cases, your documentation
should be inline with the following process.
## Security Reporting
If you wish to report a security vulnerability -- thank you! -- we ask
that you follow the following process, which complies with the Open
Source Committee Maintainers Manual.
Please fill out the following template:
Please report security vulnerabilities by filling out the following template:
* PROJECT: A URL to project's repository
* PUBLIC: Please let us know if this vulnerability has been made or discussed publicly already, and if so, please let us know where.
* DESCRIPTION: Please provide precise description of the security vulnerability you have found with as much information as you are able and willing to provide.
Please send the above info, along with any other information you feel
is pertinant to: <>.
In addition, you may request that the project provide you a patched
release in advance of the release announcement, however, we can not
gaurantee that such information will be provided to you in advance of
the public release and announcement. However ,the Open Source
Community Manager will email you at the same time the public
announcement is made.
The IEEE SA Open Source Community Manager will let you know within two
business weeks whether or not your report has been accepted or
rejected. We ask that you please keep the report confidential until we
have made a public announcement.
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