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

Commit c93035d9 authored by Alfredo Herrera's avatar Alfredo Herrera
Browse files

Update CONTRIBUTING.md

parent d62941e6
Contributing to IEEE-SA OSCom Open-Source Peer-Review ad-hoc project
===================================================================
Copyright (C) 2020 IEEE SA OSCom, peer-review ad-hoc subcommittee un der the terms of the [Apache Licence Version 2](https://opensource.ieee.org/community/peer-review/admin/-/blob/master/LICENSE).
Contributing to IEEE SA OSCom open-source peer-review ad-hoc sub-committee project
===
###### Attribution
this file is based on [Nektar++'s CONTRIBUTING.md](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md) file under an MIT License.
## Contents
This guide should provide you sufficient information to help if you're interested in contributing to IEEE-SA OSCom Open-Source Peer-Review ad-hoc committee, either in reporting bugs or, hopefully, providign ideas to fix them. This project will not produce software or hardware, but a document.
It's split up into a number of sections:
This guide should provide you sufficient information to help if you're interested in contributing to IEEE-SA OSCom Open-Source Peer-Review ad-hoc committee, either in reporting bugs or, hopefully, providign ideas to fix them. The peer-review "admin" project repository will not produce any software or hardware design; instead, it will ead to the creation of recommendations for consideration by teh IEEE SA Open Source Committee on the topic of peer-review of open source designs.
Contributing is described from the following three points of view:
- [Issues and bug reports](#issues-and-bug-reports)
- [How to contribute](#how-to-contribute)
- [Formatting guidelines](#formatting-guidelines)
## Issues and bug reports
If you believe that you have found a bug or error in the Open-Source Peer-Review documentation, we would like to know about it!
- In the first instance, you should raise an issue on the
If you believe that you have found a _bug or error_, we would like to know about it!
- To report a bug or error, please raise an issue on the
**[issue tracker](https://opensource.ieee.org/community/peer-review/admin/-/issues)** -- be
sure to do a quick search and see if anyone has reported the same thing first.
- Alternatively you can **[join the group chat# THIS IS A TEMPLATE
# Change Log
All notable changes to this project will be documented in this file.
sure to do a quick search and see if anyone has reported the same thing before to avoid duplication.
- Alternatively, you can discuss it on **[ the group chat](https://opensource-connect.ieee.org/opnsrcpeerrview)**
The format is based on [Keep a Changelog](https://opensource-connect.ieee.org/opnsrcpeerrview)** for more advice.
It's *really helpful* if you can include the context in which the bug or error can become obvious, and if possible provide a good description of the problem you're having or that you forsee hapenning.
It will be *really helpful* if you can include the context in which the bug or error can become obvious. At the minimum, please provide a good description of the problem you're having or that you forsee hapenning.
## How to contribute
If you've got improvements on the documentation or a new topic/feature, please consider contributing it back to the project. It's a pretty simple process:
If you would like to contribute improvements or add new topic/feature, please consider contributing it to the project following this simple process:
1. Fork the Peer-Review repository in `peer-review/admin` into your username's space.
2. Create a branch with the naming convention:
1. Fork the [peer-review/admin](https://opensource.ieee.org/community/peer-review/admin/-/forks/new) repository in [`opensource.ieee.org/community`](https://opensource.ieee.org/community/) project space into your own space.
2. Once in your project space, create a branch using this recommended naming convention:
- `feature/myawesomebranch`: a new feature that wasn't in Peer-Review already.
- `fix/mygreatfix`: fixes an issue that isn't tracked in the issue tracker.
- `ticket/123-myfantasticpatch`: fixes an issue that is tracked in the issue tracker (please include the issue number somewhere!)
- `tidy/mybrillianttidying`: cosmetic fixes to bring existing files up to the Peer-Review writing style guidelines.
3. Submit a merge request to merge into `master`. If you just want to see the diff and are not quite ready to merge, use the `[WIP]` tag in the title to prevent your code from being accidentally merged.
4. Put a comment in the MR saying that it's ready to be merged.
5. If your branch is a minor fix that could appear in the next patch release, then add the `Proposed patch` label to the merge request.
6. Respond to any comments in the code review.keepachangelog.com/)
and this project adheres to [Semantic Versioning](http://semver.org/).
## [Unreleased]
### Added
- CONTRIBUTING.md and CHANGELOG.md temnplates
- added Call-for-Participation.md to work on email to be sent to selected IEEE societies and Technical Councils
### Code review and merging
All merge requests will be reviewed by one of the ad-hoc committee members. We try to stick to the following process:
- An ad-hoc committee member will be assigned, MR will be assigned a milestone to target a release.
- If the branch is deemed to be minor and passes the checklist above, ad-hoc committee member will handle the request by themselves.
- Otherwise, ad-hoc committee member will ask one or more other developers to review the code.
- Where appropriate, reviewers will comment on regions of submission that need further development and/or improvement.
- Once feedback received from the branch author (if necessary) and reviewers are happy, the branch will be merged.
## Release branches
Releases are versioned in the standard form `x.y.z` where `x` is a major release, `y` a minor release and `z` a patch release. Please check the [CHANGELOG.md](https://opensource.ieee.org/community/peer-review/admin/-/blob/master/CHANGELOG.md) file for details
- `issue###/123-myfantasticpatch`: fixes an issue that is tracked in the issue tracker (please replace `###` with the issue number)
- `tidy/mybrillianttidying`: cosmetic fixes to bring existing files up to the [formatting guidelines](#formatting-guidelines) defined below.
3. Submit a merge request to merge back into the [`opensource.ieee.org/community`](https://opensource.ieee.org/community/) project space. ___Note:___ If you are merging back just to see the difference between your change and the project space code, use the `[WIP]` text at teh begining of the title of your merge request: this convention will signal to us to disregard the merged request but to keep it for your viewing.
4. When you are ready to merge your contribution, put a comment in the Merge Request saying that it's ready to be merged.
5. When applicable, please respond to any comments or questions during the merge request processing.
## Formatting guidelines
The Open-Source Peer-Review ad-hoc uses GitLab flavoured MarkDown, a language that has limited formating and document layout options. To hopefully alleviate this problem, there are a number of fairly simple formatting guidelines you should follow. We are reasonably relaxed about code formatting, but if you can follow the guidelines below this would be fantastic.
We have adopted the [GitLab flavoured MarkDown](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md) format, a language that has limited formating and document layout options. To hopefully alleviate this problem, there are a number of fairly simple formatting guidelines you should follow. We are reasonably relaxed about code formatting, but if you can follow the guidelines below this would be fantastic.
### Basic rules
- Be concise.
- Limit the numer of references to external (to the repostory) resources.
- Limit the numer of references to external resources (external to the repostory).
- Be thorough.
- Use simple gramatical constructs.
hanged
## 2020-Apr-21
### Added
- Updated README.md typos, added some clarification to bullet-form items on charter
- Added link to PDF version of charter
### Changed
- Initial README.md
- corrected typos
<!--stackedit_data:
eyJoaXN0b3J5IjpbMjA0NDgxODEwN119
-->
\ No newline at end of file
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