docs(Documentation): Minor update to contribution guide #731
Conversation
for more information, see https://pre-commit.ci
| (release notes are generated from issues). Each issue gets a **unique issue | ||
| number**. | ||
|
|
||
| ### 3. Create a local working branch |
There was a problem hiding this comment.
Would it make sense to keep this section and refine it instead of removing it? One concern I foresee is with newcomers who may end up making direct commits to their master branches. I’ve seen this happen before in my previous organization, particularly during the Google Summer of Code period.
From a technical view, we could simply add a note advising contributors to create a local branch on their fork. Rather than enforcing a strict branch-naming convention, we could present it as a suggestion.
There was a problem hiding this comment.
It probably doesn't need to be a whole section but a line in the new section 3 is not a bad idea. I propose adding simply:
Create a local branch that corresponds to the issue.
| requests. Merging of approved pull requests is done, after a second review, by the Rucio | ||
| merge team. |
There was a problem hiding this comment.
Is this second review always guaranteed? e.g. if a merger is also the reviewer, they are not allowed to merge the PR until another merger reviews it?
4 participants
Closes: #730