Process for approving PRs to master #80

Closed
opened 2 years ago by lhinderberger · 5 comments

Hey Documentation contributors 👋

I'm wondering how we should go about handling the approval/review of PRs now that there's regular activity in this regard (of which I'm very very happy - thank you all! 😊):

I personally think for smaller changes (such as bug/typo fixes or minor wording corrections), it's okay for collaborators on the repo to simply go ahead and merge/commit to master and deploy to live.

For somewhat larger changes though, the question is: Which rules should we give ourselves for merging and deploying them?

I would suggest that larger changes should need to be reviewed and approved by two other collaborators before merging, with a first-come-first-served method of determining who gets to review a PR (so, the first collaborator willing to review would go ahead and review without being explicitly asked to do so). After merging, the PR can be deployed to live.

In addition, for certain critical changes, e.g. ones that affect Codeberg e.V., I think we should also always ask @hw for approval.

What do you think - would that method be sufficient?

Hey Documentation contributors 👋 I'm wondering how we should go about handling the approval/review of PRs now that there's regular activity in this regard (of which I'm very very happy - thank you all! 😊): I personally think for smaller changes (such as bug/typo fixes or minor wording corrections), it's okay for collaborators on the repo to simply go ahead and merge/commit to master and deploy to live. For somewhat larger changes though, the question is: Which rules should we give ourselves for merging and deploying them? I would suggest that larger changes should need to be reviewed and approved by two other collaborators before merging, with a first-come-first-served method of determining who gets to review a PR (so, the first collaborator willing to review would go ahead and review without being explicitly asked to do so). After merging, the PR can be deployed to live. In addition, for certain critical changes, e.g. ones that affect Codeberg e.V., I think we should also always ask @hw for approval. What do you think - would that method be sufficient?
lhinderberger added the
Status: Needs feedback
Kind: Question
labels 2 years ago
lhinderberger changed title from Process for approving PRs to Process for approving PRs to master 2 years ago

It all sounds good to me!

It all sounds good to me!
n commented 2 years ago
Collaborator

Sounds good to me!

Sounds good to me!
Poster

And there has been a thumbs-up from hw too on the original post.

So if noone else objects to this process until next weekend, I'd document it in the Contributor FAQ and close the issue then.

Thank you all for your feedback :)

And there has been a thumbs-up from hw too on the original post. So if noone else objects to this process until next weekend, I'd document it in the Contributor FAQ and close the issue then. Thank you all for your feedback :)
lhinderberger removed the
Status: Needs feedback
label 2 years ago
Poster

I propose to lower the count of other contributors required for approving changes from 2 to 1, because we're a rather small team at the moment and I think it would speed up the whole process and make it less buerocratic.

I propose to lower the count of other contributors required for approving changes from 2 to 1, because we're a rather small team at the moment and I think it would speed up the whole process and make it less buerocratic.

I propose to lower the count of other contributors required for approving changes from 2 to 1, because we're a rather small team at the moment and I think it would speed up the whole process and make it less buerocratic.

I have no overview of how many people (can) contribute. But I tend to think that it's always good to have someone not involved in the discussion/development from the beginning to check the final "product", like an outsider with a fresh look, if you see what I mean.

At the end, it probably just depends on how much changes are involved and how critical these changes are. For more important changes, I would still recommend 2 reviewers. But that's only my own opinion!

> I propose to lower the count of other contributors required for approving changes from 2 to 1, because we're a rather small team at the moment and I think it would speed up the whole process and make it less buerocratic. I have no overview of how many people (can) contribute. But I tend to think that it's always good to have someone not involved in the discussion/development from the beginning to check the final "product", like an outsider with a fresh look, if you see what I mean. At the end, it probably just depends on how much changes are involved and how critical these changes are. For more important changes, I would still recommend 2 reviewers. But that's only my own opinion!
n referenced this issue from a commit 1 year ago
n added the
Part: Generator
label 1 year ago
n closed this issue 1 year ago
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.