Autres/audacity
1
0
Fork 0
mirror of https://github.com/cookiengineer/audacity synced 2025-04-29 23:29:41 +02:00
Code Issues Releases Wiki Activity

CONTRIBUTING.md: Clarify when it is okay to merge changes (#627)

Browse Source 
Wrote down some unspoken rules, such as the waiting times before a maintainer
is supposed to merge a change, and added some exceptions to those said rules
that make the development process of Tenacity more tedious and unproductive.

The said exceptions concern documentation-related changes.

Signed-off-by: Panagiotis Vasilopoulos <hello@alwayslivid.com>
Reference-to: https://github.com/tenacityteam/tenacity/pull/627
This commit is contained in:
Panagiotis Vasilopoulos 2021-09-16 12:00:51 +02:00 committed by GitHub
parent 3aa5d73a31
commit b3c163adce
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 21 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
CONTRIBUTING.md
View File

@ -245,9 +245,29 @@ important:
rebase the patch on top of the `master` branch just to be sure that the most
recent changes do not cause the proposed patch to break.
* In order to accommodate other reviewers that live in different timezones,
the rule of thumb is to wait for up to a day before merging a change that
has been approved by a reviewer, or wait around 12 hours before merging a
change that has been approved by multiple people. If possible, make sure to
check the change for yourself if possible, especially when a reviewer
approves a change reluctantly.
* Before merging any change, make sure that all (or, at the very least, *most
of*) the tests have passed. If a change concerns a particular platform (e.g.
macOS), then wait for the tests for that said platform to complete.
* If a change affects the user interface or the audio engine, you're generally
expected to use Tenacity with the included change on your machine and
evaluate it. Since it's very hard to answer whether a specific change
affecting the experience of the user is worth including or if the contributor
should adjust their change, you may want to ask for the help of other
contributors.
* If there are multiple proposed changes that affect the same parts of the
project, ***please wait*** for a while after initially merging a single
proposed change just to be sure that this will not break the build.
proposed change just to be sure that this will not break the build. This does
not apply to changes that do not affect the functionality of the program
(such as changes to a Markdown file).
The most basic way of evaluating whether two separate changes affect the same
part of the project is checking whether the changes concern the same source