Process for approving PRs to master #80

lhinderberger commented 2020年09月22日 23:09:58 +02:00

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?

ivan-paleo commented 2020年09月23日 16:25:59 +02:00

It all sounds good to me!

It all sounds good to me!

n commented 2020年09月26日 11:50:39 +02:00

Sounds good to me!

Sounds good to me!

lhinderberger commented 2020年09月26日 11:55:28 +02:00

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 commented 2020年10月20日 16:17:26 +02:00

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.

ivan-paleo commented 2020年10月20日 16:40:15 +02:00

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!