4rkal/monero
1
0
Fork 0
mirror of https://github.com/monero-project/monero.git synced 2025-02-22 17:50:20 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity

docs: remove 'Monero Maintainer Team'

Browse Source
This commit is contained in:
tobtoht 2025-01-26 15:10:23 +01:00
parent 90359e31fd
commit 69020aa0b3
No known key found for this signature in database
GPG Key ID: E45B10DD027D2472
1 changed files with 1 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
docs/CONTRIBUTING.md
View File

@ -77,11 +77,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:
@ -146,7 +141,7 @@ C4 is meant to provide a reusable optimal collaboration model for open source so
- 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 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 Maintainers.
- 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.