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

Commit 99442736 authored by Andrew Oram's avatar Andrew Oram
Browse files

Add new file

parent 8371ec69
# CONTRIBUTING.md
We welcome contributions from everyone and appreciate your consideration in helping us to improve our code, tests, and documentation.
## Contributor License Agreement (CLA)
For any contribution to be accepted to this project, you must have already submitted an appropriate CLA to oscontrib@ieee.org and have received from IEEE staff a CLA number.
## Help Wanted
Task: Documentation review
Knowledge required: Subject-matter knowledge in the area of communities being discussed
Deadline: February 14, 2021
## Bug reporting
We encourage people to report bugs. Please read [How to Submit a Good Bug Report](https://github.com/theopensourceway/guidebook/blob/master/bug_report.adoc) before submitting your report. The most important advice from there is: 1) do as thorough a search as you can to see whether the bug has already been reported, and 2) be as precise and complete as you can when reporting a new bug.
To report a bug:
1. Go to the appropriate project.
2. Click the Issues button on the left of the window.
3. Click the "New issue" button.
4. Fill out the Title and Description. You don't need to fill out the other fields. (Shall we encourage readers to use the Label field?)
## Other Issues
The issue tracker is used for many issues besides bugs. Please read the [Issues web page](https://opensource.ieee.org/help/user/project/issues/index.md) created by IEEE SA Open for guidelines. Before suggesting an issue. please look over our milestones and issue boards to see whether your feature has already been listed.
After you create an issue, our team will assign a priority to the issue, ensure it is labeled properly, and perhaps request additional information from you.
## Roadmap
[Community Strategy Roadmap](https://opensource.ieee.org/andyo/community-strategy-roadmap/-/blob/main/community_roadmap.md)
## Cloning, Branching, and Merging
Anyone contributing source code should clone the project (also known as *forking*) using Git commands. The term *fork* in GitLab differs from an older meaning of the word, which referred to people breaking away from a project and starting a new one. Here, *fork* just means that someone creates their own personal copy, and intends to push changes back to the project.
Git also allows multiple branches of a project. Here you can list your policy for creating a branch and for accepting code back into the main branch.
Submitting code to a project is called a *pull request*. A comprehensive [Gitlab document](https://docs.gitlab.com/ee/topics/gitlab_flow.html) describes various robust workflows for handling pull requests. We recommend that you adopt one of those workflows.
Although most pull requests fix bugs or add features, a pull request can offer more specific contributions as well, such as a test for a bug or a feature.
### Merge request acceptance criteria
Your merge request needs at least one approval from a maintainer on the project, but depending on your change you might need additional approvals. Merge requests that fix a regression are usually accepted quickly and usually only require a single approval, whereas a new feature may require approval from multiple maintainers and our project leads.
## Code of conduct
Please read the [IEEE Code of Conduct](https://www.ieee.org/content/dam/ieee-org/ieee/web/org/about/ieee_code_of_conduct.pdf), which governs projects on IEEE SA OPEN.
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