oxen-io
/
oxen-core
mirror of https://github.com/oxen-io/oxen-core.git
2
1
Fork 0
Code Issues Projects Releases Wiki Activity

Update contribution rules: Monero -> Oxen 

CONTRIBUTING.md is shown to all first-time users opening an issue,
so seeing "Monero" at the top is rather disorienting.
This commit is contained in:
Chris Buccella 2021-03-17 22:41:55 +00:00 committed by Jason Rhinelander
parent c719d45518
commit bdba579564
1 changed files with 5 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
CONTRIBUTING.md
View File

@ -1,4 +1,4 @@
# Contributing to Monero
# Contributing to Oxen
A good way to help is to test, and report bugs. See
[How to Report Bugs Effectively (by Simon Tatham)](https://www.chiark.greenend.org.uk/~sgtatham/bugs.html)
@ -12,10 +12,7 @@ of software solid and usable.
* If modifying code for which Doxygen headers exist, that header must be modified to match.
* Tests would be nice to have if you're adding functionality.
Patches are preferably to be sent via a Github pull request. If that
can't be done, patches in "git format-patch" format can be sent
(eg, posted to fpaste.org with a long enough timeout and a link
posted to #monero-dev on irc.freenode.net).
Patches are preferably to be sent via a Github pull request.
Patches should be self contained. A good rule of thumb is to have
one patch per separate issue, feature, or logical change. Also, no
@ -68,11 +65,6 @@ You should have received a copy of the GNU General Public License along with thi
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
The "Monero Maintainer Team" is defined in this document as the following users:
- fluffypony
- moneromooo
- hyc
## Goals
C4 is meant to provide a reusable optimal collaboration model for open source software projects. It has these specific goals:
@ -127,7 +119,7 @@ C4 is meant to provide a reusable optimal collaboration model for open source so
- To request changes, a user SHOULD log an issue on the project Platform issue tracker.
- The user or Contributor SHOULD write the issue by describing the problem they face or observe.
- The user or Contributor SHOULD seek consensus on the accuracy of their observation, and the value of solving the problem.
- Users MUST NOT log feature requests, ideas, or suggestions unrelated to Monero code or Monero's dependency code or Monero's potential/future dependency code or research which successfully implements Monero.
- Users MUST NOT log feature requests, ideas, or suggestions unrelated to Oxen code or Oxen's dependency code or Oxen's potential/future dependency code or research which successfully implements Oxen.
- Users MUST NOT log any solutions to problems (verifiable or hypothetical) of which are not explicitly documented and/or not provable and/or cannot be reasonably proven.
- Thus, the release history of the project MUST be a list of meaningful issues logged and solved.
- To work on an issue, a Contributor MUST fork the project repository and then work on their forked repository.
@ -135,9 +127,9 @@ C4 is meant to provide a reusable optimal collaboration model for open source so
- A Contributor MUST NOT commit changes directly to the project.
- To discuss a patch, people MAY comment on the Platform pull request, on the commit, or elsewhere.
- To accept or reject a patch, a Maintainer MUST use the Platform interface.
- Maintainers SHOULD NOT merge their own patches except in exceptional cases, such as non-responsiveness from other Maintainers for an extended period (more than 30 days) or unless urgent as defined by the Monero Maintainers Team.
- Maintainers SHOULD NOT merge their own patches except in exceptional cases, such as non-responsiveness from other Maintainers for an extended period (more than 30 days) or unless urgent as defined by the Maintainers Team.
- Maintainers MUST NOT make value judgments on correct patches unless the Maintainer (as may happen in rare circumstances) is a core code developer.
- Maintainers MUST NOT merge pull requests in less than 168 hours (1 week) unless deemed urgent by at least 2 people from the Monero Maintainer Team.
- Maintainers MUST NOT merge pull requests in less than 168 hours (1 week) unless deemed urgent by at least 2 people from the Maintainer Team.
- The Contributor MAY tag an issue as "Ready" after making a pull request for the issue.
- The user who created an issue SHOULD close the issue after checking the patch is successful.
- Maintainers SHOULD ask for improvements to incorrect patches and SHOULD reject incorrect patches if the Contributor does not respond constructively.