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

Commit 86e7f346 authored by Joshua Gay's avatar Joshua Gay 🙀
Browse files

First draft

parent 7f37fa15
## 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
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 <>.
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).
## Responsibilities of Maintainer
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.
* Responding to communication and notificatoins on the IEEE OPen Source Platform in a timely manner.
### Terminology
When communicating about policies, procedures, or other rules, the following
definitions should be followed: **shall** means "is required to", **should**
means "is recommended that".
The pronoun they, or in its inflected forms (them, their, theirs, and themself),
should be used as a gender-neutral singular pronoun.
## 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.
## 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)
### Communication
* Expectations on maintainer when communicating with other participants
## Organization of Project Materials
### Group and Project
How an IEEE Open Source Project may use one group area (namespace) on the IEEE OPen Source Platform, although subgroups of that group are permitted.
An IEEE Open Source Project may organize there work into varoius different project areas within their designated group area.
### Repository
Each open source project area that makes use of a git repository shall have the following files:
* CONTRIBUTING (Governance and Code-of-Conduct)
### Licensing and legal notices
* README file notice and notice in header
* Draft standard notice
## Release and distributions
* Project release requirements
## Critical vulnerabilities
### Process and Procedure
### Private notifications
### Public notifications
### Response and resolution time periods
* Time period for acknowledgin the validity of a critical vulnerability or exposure or similar notification: 15 days
* Total time period required to resolve the issue: 90 days
## Archiving
* How and when to move a project to an archived project
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