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

Skip to content
GitLab
Commit e0d1d716 authored by IEEE SA OSCM's avatar IEEE SA OSCM
Browse files

Updates with version approved by OSCom. 


Signed-off-by: IEEE SA OSCM's avatarOpen Source Community Management Team <opensource@ieee.org>
Signed-off-by: Joshua Gay's avatarJoshua Gay <j.gay@ieee.org>
parent 56313729
Hide whitespace changes
Inline Side-by-side
content/conduct.md deleted 100644 → 0
View file @ 56313729
## Policy, Ethics, and Code of Conduct
IEEE supports open source as one method for consensus development
within its portfolio of collaborative activities. Your participation
as a Leader, Maintainer, or Contributor of any IEEE Open Source
Project and/or your use of the IEEE Open Source Platform is contingent
upon, although not limited to, your agreement to comply with this
manual, the IEEE SA OPen Source Committee Operations Manual, and the
following:
<details>
<summary>All applicable IEEE policies and procedures, including but not limited to:</summary>
* [IEEE Code of Conduct](https://www.ieee.org/content/dam/ieee-org/ieee/web/org/about/ieee_code_of_conduct.pdf)
* [IEEE Code of Ethics](https://www.ieee.org/about/corporate/governance/p7-8.html)
* [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](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)
* [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)
* Antitrust and Fair Competition Policy (§12.10)
* Civility Policy (§9.25)
* Computer Policy (§9.28)
* Economic Sanctions and Embargoes Policy (§12.11)
* IEEE Records Management Policy Statement (§12.8)
* IEEE Social Media Policy (§9.27)
* Whistleblower and Non-Retaliation Policy (§9.9)
* Remain consistent with definitions of Bullying, Discrimination, Harassment, Retaliation (unumbered front matter text)
</details>
<details>
<summary>CLAs and Preserve Appropriate Legal Notices </summary>
* Submit any applicable
[IEEE Contributor License Agreement](https://opensource.ieee.org/community/cla](https://opensource.ieee.org/community/cla) (CLA) where required by specific IEEE Open Source Projects.
* Post and preserve any and all appropriate legal notices (e.g.,
copyright and license file headers) where the license or relevant
IEEE policy requires.
</details>
<details>
<summary>CLAs and Preserve Appropriate Legal Notices </summary>
* Submit any applicable
[IEEE Contributor License Agreement](https://opensource.ieee.org/community/cla](https://opensource.ieee.org/community/cla) (CLA) where required by specific IEEE Open Source Projects.
* Post and preserve any and all appropriate legal notices (e.g.,
copyright and license file headers) where the license or relevant
IEEE policy requires.
</details>
<details>
<summary>In addition we recommend that you adhere to the following terms: </summary>
We recommend that all individuals involved in the design and
development of autonomous and intelligent systems as part of their
participation in an IEEE Open Source Project to strive to be educated,
trained, and empowered to prioritize ethical considerations in the
design and development of autonomous and intelligent systems. The
[IEEE Global Initiative for Ethical Considerations in Artificial
Intelligence and Autonomous
Systems](http://standards.ieee.org/develop/indconn/ec/autonomous_systems.html)
supports those seeking ot satisfy this recommendation; the
Initiative's mission statement is as follows:
> To ensure every stakeholder involved in the design and development of
> autonomous and intelligent systems is educated, trained, and empowered
> to prioritize ethical considerations so that these technologies are
> advanced for the benefit of humanity.
</details>
<details>
<summary>Ethics and Compliance Helpline</summary>
Reports of violations, or concerns regarding potential violations, of
IEEE Policies or the IEEE Code of Conduct can be filed anonymously
through EthicsPoint:
* :telephone_receiver: Call the 24-hour phone number: +1(888)359-6323
* :computer: [Submit an online report](https://secure.ethicspoint.com/domain/en/report_custom.asp?clientid=20410)
</details>
\ No newline at end of file
content/guides/project-setup.md deleted 100644 → 0
View file @ 56313729
## Setting up an Official IEEE Open Source Project
Your Official IEEE Open Source Project may contain one or more
projects on opensource.ieee.org. Each project should contain the
following files in the project's git repository:
* README.md - Info about your project (see below for more detailed example)
* LICENSE - A copy of the project's license; this should be taken from the appropriate license file in https://opensource.ieee.org/community/cla/licenses
* AUTHORS.md - A list of copyright holders
* CONTRIBUTORS.md - A list of contributors
Additional files you may want to have or may need to have:
* NOTICES.md - Additional legal notices
* contributing.md - Policies for how you would like to accept contributions
* security.md - Policy on how to handle CVEs
## README
Your project's README file should provide at minimum information about
your project, how to contribute (including license/CLA info), and a
list of the project's lead(s) and/or maintainer(s). Some additional
sections and info are recommended. Below is a list of various
recommended sections.
Also, have fun. Use emoji. Be friendly and welcoming.
### Detail contents of a simple README file
* :mag_right: About
* 1-2 paragraphs describing the purpose of the project
* License
```
All source code files in this repository are subject to the following copyright and licensing terms.
Copyright 2020 NAME or GROUP-NAME
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.
```
* :checkered_flag: Getting Started
* :hammer_and_wrench: Requirements or preconditions needed to install the software or any assumptions.
* :page_with_curl: Instructions (step-by-step guide) to get a copy of the project up and running on a peron's local machine for use, development, and/or testing.
* Usage - any additional usage notes on using the software
* :unicorn: Project leadership
* Project Lead (username)
* Project maintainer name (username)
* :gift: Contributing
* This project is licensed under the terms of the (LICENSE NAME). Contributions are accepted under a Contributor License Agreement (LINK to appropriate project https://opensource.ieee.org/community/cla/). See (LINK to contributing.md) for more
* :speech_balloon: Communicating
* Link to any mailing list
* Link to public mattermost channel
* :tada: Acknowledgements
* See CONTRIBUTORS.md for a list of contributors and AUTHORS.md for a list of authors.
* Any additional thanks, etc. you wish to add (e.g., another project that provided inspiration, etc).
content/maintain.md
View file @ e0d1d716
# 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.
## TOC
* Conduct
* Organization of Projects and Materials
* Homepage
* Repository
* Appropriate legal notices
* Responsibilities of Maintainers and Committers
* Stepping Down
* Security and Critical vulnerabilities
* Communication
* Naming, Branding, Trademark, and Tradename
* Archiving
## 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>.
### 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
#### README
On the IEEE Open Source Project's README file, the following information shall be included:
* 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
### 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).
## IEEE Open Source Maintainers Manual
**Contents**
[TOC]
Copyright 2020, Maintainers Manual Authors
This manual is licensed to you under the Apache License, Version 2.0 (the "License").
## 1 Scope and Purpose
### 1.1 Welcome to IEEE Open Source
IEEE Standards Association (IEEE SA) supports Open Source as a model for technical innovation. IEEE SA has established its IEEE Open Source Platform ("the Platform") as a resource for the IEEE Open Source Community. The Platform provides a means of collaboration through the sharing of information and digital products with the clear intention of contributing to the success of an open source computer executable, hardware component or standard document. Open source allows access for multiple participants to inspect, modify, enhance, and utilize software, hardware, and other Open Source content. The Platform supports a variety of uses, including software incorporated in IEEE standards, projects focused on practical applications and humanitarian initiatives, individual education-related projects, and industry collaborative projects.
The Platform includes Gitlab/GitHub support, code repository procedures and support, license management support, and technical assistance, including support for testing and peer review, as well as links to self-help and training material.
IEEE offers many Technical Communities that offer opportunities for increased connection and awareness of developments. As used in this manual, the IEEE Open Source Community refers to all users with an authorized account on the Platform, all individuals and entities (e.g., governmental entities and corporations) with a valid IEEE open source Contributor License Agreement, and relevant members of IEEE volunteer governance and staff. If you have a free IEEE account and accept the Terms of Use and Contributors License Agreement (CLA), you can join the IEEE Open Source Community (details in Section 3).
This _IEEE Open Source Maintainers Manual_ provides policies, guidelines, advice, and requirements for Project Leads, Maintainers, Contributors and other participants using the Platform or involved in an IEEE Open Source project (see section 2 for roles and responsibilities). This _IEEE Open Source Maintainers Manual_ is also available as an Open Source project itself, with links to detailed procedures, templates for common files, sample guides, scripts, and various resources and materials that you can use to produce project-specific documentation and other resources for an Open Source project.
An Open Source project is the place on the Platform where you keep your files (repository), develop your end-product (contributions), plan your work or improve its quality (issues), describe its inner-workings (wiki) and release or publish completed working version of your project (project governance policies). The Platform supports several categories of projects:
* IEEE Open Source Standards projects (results of the Open Source project will be incorporated as normative or informative content of an IEEE standard)
* Joint IEEE projects (undertaken in collaboration with an external entity)
* Official IEEE Open Source projects (Official IEEE releases are approved by IEEE OSCom)
* Group projects (multiple participants, no specific organizational alignment with IEEE)
* Individual projects (only one person involved in the project)
Projects are also classified by visibility:
* **_Private:_**The Maintainer grants project access explicitly to each user. All users are Open Source Community members. The OSCom Community Manager and Platform administrators do have access.
* **_Internal:_** The project can be accessed by any IEEE Open Source Community member.
* **_Public:_**The project can be accessed without any authentication to view and download.
### 1.2 Useful resources
Sign in to the **_Maintainers community_** here:
[https://opensource.ieee.org/users/sign_in](https://opensource.ieee.org/users/sign_in)
Access the online version of this IEEE Open Source _Maintainers Manual_ here:
[https://opensource.ieee.org/community/manual](https://opensource.ieee.org/community/manual)
Get **_help or report concerns_** with the Platform here:
&lt; [https://opensource.ieee.org/help](https://opensource.ieee.org/help)>
&lt; [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:
📞 Call the 24-hour phone number: +1(888)359-6323
💻[ Submit an online report](https://secure.ethicspoint.com/domain/en/report_custom.asp?clientid=20410): [https://secure.ethicspoint.com/domain/en/report_custom.asp?clientid=20410](https://secure.ethicspoint.com/domain/en/report_custom.asp?clientid=20410)
## 2 IEEE Open Source governance
### 2.1 Governance principles
In this manual, "shall" is used to indicate a mandatory requirement.
Project governance clarifies accountability for decision-making and enables conformance with applicable administrative, technical, security, and licensing requirements. Projects on the Platform are governed with various degrees of oversight and formality depending on their category, size, purpose, and incorporation into the IEEE brand.
Project governance may be provided by a single individual or organization; by a closed or open set of individuals or organizations; via a collaborative process among active contributors; through a consensus-driven process; or in some other manner. In all projects, it is necessary to identify all participants and to have clear definitions of who has the authority to take actions that affect the integrity of all or part of the source code, product releases, and the security of the Platform.
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;
* How merge requests are handled;
* How and when releases are evaluated or reviewed; and
* Who decides when a release can be made.
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_.
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.
### 2.3 Open Source project roles and responsibilities
Regardless of category, all Open Source projects have specific roles with defined responsibilities and privileges. In an individual project, the same person has all the roles and responsibilities.
The primary roles for projects are the following:
* Project Lead
* Maintainer
* Committer
* Contributor
* User
Each IEEE Open Source project has a Project Lead and at least one Maintainer (who could be the same as the lead), as defined in the _[IEEE SA Open Source Committee Operations Manual](https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/other/OSCOM_Operations_Manual.pdf)_. These are listed on the application for the Platform use as approved by OSCom. They continue in their roles for the life of the project, or until replaced.
Anyone who has the authority to contribute to the project is called a Contributor, and anyone with the authority to commit changes (e.g. approve pull requests or merge requests) is called a Committer. Users have the ability to view and download Open Source products for use outside the project or the Platform, consistent with the project's license and any additional applicable terms (e.g., terms for use of the IEEE Trademark).
Project Leads and Maintainers who can no longer carry out their responsibilities should inform the Community Manager via an email to [contrib@ieee.org](mailto:contrib@ieee.org), and if possible suggest a replacement. Note that any new Maintainers shall be approved by the Project Lead and new Project Leads shall be approved by the Community Manager. Also, additional approval is required for appointment and replacements of Project Leads and Maintainers associated with IEEE Open Source Standards projects, see section 6.)
**_Responsibilities of Project Leads._**Project Leads are responsible for the vitality, organization, development, evaluation, operation, security, and maintenance of an IEEE Open Source project. They act as the official point of communication with OSCom, the Community Manager, other parts of IEEE, other organizations, and the public for the projects they lead. Project Leads work closely with the Maintainer(s). Larger projects can choose to appoint or elect associate or alternate Project Leads and other coordinators, such as a communications coordinator or comments resolution lead.
**_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;
* Designating Committers (in accordance with the project’s governance rules);
* Responding in a timely manner to relevant communications and notifications posted on the Platform;
* Responding to issues, merge requests, and other communications from the Project Lead and the Community Manager.
**_Responsibilities of Committers._**Committers (including all Maintainers) are responsible for adhering to the governance rules for their project and the governance rules that apply to all IEEE Open Source projects. Committers are responsible for checking that contributions are properly marked to disclose intellectual property (see Section 8.3 for details).
**_Responsibilities of Contributors._**Anyone who reviews and comments or posts any material on the Platform or in any project is a Contributor. Contributors represent that they have the right to allow use of the material on the Platform. Contributions to an IEEE Open Source project can only be made under the terms of an applicable and appropriate [Contributor License Agreement](https://opensource.ieee.org/community/cla) (CLA) as described in Section 8 (Licensing Policies). CLAs may be submitted by an individual Contributor or by their organization. Contributors perform due diligence on their contributions.
**_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.1 Using the IEEE Open Source Platform
Everyone using the Platform is required to obtain an IEEE account and to read and accept the IEEE Privacy Policy. There is no charge for an IEEE account. The registration page is available at [https://www.ieee.org/profile/public/createwebaccount/showRegister.html](https://www.ieee.org/profile/public/createwebaccount/showRegister.html)<span style="text-decoration:underline;"> <span style="text-decoration:underline;"></span>
The privacy policy is available at
<span style="text-decoration:underline;"> <span style="text-decoration:underline;"> [https://www.ieee.org/security-privacy.html](https://www.ieee.org/security-privacy.html?WT.mc_id=hpf_priv)</span>
You will also need to accept the IEEE CLA license terms, as explained further in Section 8.
### 3.2 Requesting an Open Source project
Learn the features of a GitLab project here:
&lt; [https://opensource.ieee.org/help/user/project/index.md#projects-features](https://opensource.ieee.org/help/user/project/index.md#projects-features)>
To request a new Open Source project in the Platform, or to change a Project from one category to another, use the application form available here:
[https://opensource.ieee.org/projects/new](https://opensource.ieee.org/projects/new)
You will need to enter the following information:
* Project category;
* Project title;
* Project description (purpose);
* The name and contact information (as stated in the IEEE account) of the Project Lead;
* Name and contact information (IEEE account) of the Maintainer;
* Selection of a single Open Source license and associated CLAs (see section 8, Licensing);
* An indication of how the project will be governed;
* 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>
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.
All features are enabled for blank projects or when importing from Platform templates, but you can disable optional features afterward in the project settings.
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
* AUTHORS - A list of copyright holders
* CONTRIBUTORS - A list of contributors
* SECURITY.md – The baseline security and critical vulnerability and exposure policy
These files shall remain at the topmost level of your Open Source project.
A sample file for project startup is here:
[https://opensource.ieee.org/oscom/maintain/blob/master/content/templates/READEME_simple.md](https://opensource.ieee.org/oscom/maintain/blob/master/content/templates/READEME_simple.md)
If you are anticipating a complex open source effort, you may choose to organize your namespace as a Group with collaboration across multiple dependent projects. For example, you can have one dependent project open to public access, and other dependent projects where your development team works. Your Group can have nested subgroups as well. You can apply for a Group here:
[https://opensource.ieee.org/groups/new](https://opensource.ieee.org/groups/new)
More help on getting started with a project, available elements, and using templates and sample pages is here:
[https://opensource.ieee.org/help/user/project/pages/index.md#getting-started](https://opensource.ieee.org/help/user/project/pages/index.md#getting-started)
## 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)
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.
### 4.1 Delegating responsibility and access control
One of the first steps in setting up a project is for the Maintainer to grant access to all the expected Maintainers, Committers, and (for Private and Internal projects) Contributors and users. It is advisable that projects of all sizes have alternate Maintainers as a backup. The primary Maintainer should grant other Maintainers and Committers access to all relevant repositories.
Changes in Project Leads and the primary Maintainer should be promptly reported to the Community Manager and (as applicable) to the related IEEE organization. Projects without an active Project Lead or Maintainer for a period of more than 45 days may be shut down without further notice (see Section 7, Retiring a project).
### 4.2 Forking, branching, and merging
Branching and forking are two accepted development flows. Generally, established projects on the Platform use branching to collaborate on the same repository, and forking for distributed development, such as among subgroups. On the Platform, forks will be considered individual sub-projects: if you fork a group or official IEEE project, then you become by default the Maintainer of the new fork, and you become responsible for version control and version numbering within the new fork and its submodules. Any changes merged with the original project will be considered part of that project upon approval by its primary Maintainer.
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)
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
* Patches provided by the Platform to be applied to your project.
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)
### 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)
### 4.5 Peer reviewing
The peer review process for Open Source projects permits peer reviewers to evaluate project information in collaboration with the project, subject to the governance rules adopted by project members. For IEEE Open Source projects and selected group projects, peer review is offered to add value and improve quality. Peer review can be undertaken at any point in project development, such as requirements review, software design, and pre-release code walkthroughs. It is an extension of the internal reviews that every large project should include and is valuable for smaller projects as well.
Open Source projects intentionally build on previous development and the work products are offered for continued creative development and exploitation. IEEE Open Source peer review is intended to affirm technical merit and identify areas needing improvement, and to suggest corrections in a positive way. It may also involve checking for bugs, missing features, and vulnerabilities with the aim of improving the product. It can also expose copyright infringement.
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.
All inquiries about specific projects should be referred to the Project Lead for response. Communications should make clear whether they represent an individual viewpoint or a position of the Open Source project. Governance documents for projects should designate a means of approval of public statements and a person (usually, the Project Lead) who is responsible for communications made in the name of the project.
Informal communications, or communications from group or individual projects that are not IEEE Official Open Source projects, shall not imply that the message is a formal position of IEEE, IEEE SA, or the IEEE Open Source community. Such communications shall not bear the logos of IEEE, IEEE SA, or any other part of IEEE such as an IEEE technical society, standards committee, or working group.
Communications from Official IEEE Open Source projects require approval of the Community Manager, who may consult with OSCom. If the project is associated with an IEEE technical group, the public communication should also be approved by the relevant officer of that group according to its policies.
Communications from joint Open Source projects between IEEE and another entity usually require approval of both entities.