Update BEMAN_STANDARD: REPOSITORY.CODEOWNERS

[neatudarius]

#101

Add a default codeowners group for reviews.

First usage example -> bemanproject/exemplar#130.

[wusatosi]

What is the motivation here?

[neatudarius]

What is the motivation here?

bemanproject/exemplar#130 (comment)

Already been discussed and voted in the weekly beman sync. We can only discuss/tune who to be in the team.

[wusatosi]

Sorry I didn't realize you're trying solve the "we need more reviewer issue", I thought I missed something at the sync.
So my original concern about spamming people is addressed (or more specifically, I see the tradeoff now).

Seems like we did not discuss this explicitly,
can we rename the bemanproject/beman-codeowners team to something like bemanproject/common-reviewers to make this more explicit. beman-codeowners is a confusing name that does not describe the intent of this team.

[neatudarius]

Sorry I didn't realize you're trying solve the "we need more reviewer issue", I thought I missed something at the sync. So my original concern about spamming people is addressed.

Seems like we did not discuss this explicitly, can we rename the bemanproject/beman-codeowners team to something like bemanproject/common-reviewers to make this more explicit. beman-codeowners is a confusing name.

I agree with renaming. bemanproject/default-codeowners? That way we suggest to add local reviewers.

[wusatosi]

Sorry I didn't realize you're trying solve the "we need more reviewer issue", I thought I missed something at the sync. So my original concern about spamming people is addressed.
Seems like we did not discuss this explicitly, can we rename the bemanproject/beman-codeowners team to something like bemanproject/common-reviewers to make this more explicit. beman-codeowners is a confusing name.

I agree with renaming. bemanproject/default-codeowners? That way we suggest to add local reviewers.

I do not agree with the nameing default-codeowners, this team is created to aid review. I do not want to "own" all the libraries in beman, but I am happy to help "review" changes in all libraries.

A personal looking at default-codeowner will not see it's intent is "this is a group of people that can help with review PRs".

I propose something like core-reviewers or common-reviewers.

Naming is hard, @camio any good suggestions here?

[wusatosi]

I do also want to point out, we agreed on "we need more reviewer" and we agreed on "this is a good way to do it", but not exactly who is in this team.

Since I understood the intent, I am more than happy to be in this team.

But I do want to suggest that we start this with a minimal team that agreed to this at the sync, as I have mentioned, people in this team will be significantly spammed, receiving basically all new PRs, subsequent conversations, reviews across beman.

I suggest we post something in the discourse about this, people should choose to "opt in" to the team, having such a change posted on discourse is also required in the standard itself.

[neatudarius]

I do also want to point out, we agreed on "we need more reviewer" and we agreed on "this is a good way to do it", but not exactly who is in this team.

Since I understood the intent, I am more than happy to be in this team.

But I do want to suggest that we start this with a minimal team that agreed to this at the sync, as I have mentioned, people in this team will be significantly spammed, receiving basically all new PRs, subsequent conversations, reviews across beman.

I suggest we post something in the discourse about this, people should choose to "opt in" to the team, having such a change posted on discourse is also required in the standard itself.

We can review ask people in the next sync of they want in. Let's not delay something we already decided, please. I'm happy to have a 2-3 people team meanwhile.

[camio]

Naming is hard, @camio any good suggestions here?

I don't have any good ideas here. I'm happy with whatever y'all are happy with.

[wusatosi]

I disagree with current naming, but I will leave the decision to @bemanproject/leads

[neatudarius]

@JeffGarland , this seems to be a style related issue (the name of the group). Can you make a decision?

[JeffGarland]

Hmm, well this might be a bit more than a style issue -- but regardless here's my thoughts. This is, in fact a github thing: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners

So I don't think we really get to decide on the name here even if I agree with @wusatosi that the name might be somewhat misleading. So I think the PR is technically correct, but I'd like to see the reference above included in the standard. Also, as @wusatosi notes the beman core code owners will be spammed, but like @wusatosi I'm ok with that! Others may want to remove themselves from various repos. As this project grows it might become a bit overwhelming - I really hope so :)

[JeffGarland]

suggest we add a reference to github codeowners info https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners

[wusatosi]

@JeffGarland just to make it clear, we are asking for a good name for the review team (what comes after @bemanproject/) in the mention.

The original proposed team name is beman-codeowners, which I complained is not descriptive for it's purpose. Darius then changed it to default-codeowners, which I am still not happy about.

I was proposing something like common-reviewers.

I think Darius is looking at the name from a where-it-is perspective, as in "these are the default people we put into all our codeowner file".

I disagree as I think it is not descriptive for its actual intent, that is "this is a team of reviewers every repo will request review from". See: #99 (comment)

I am not objecting to the use of codeowner, as it is the only way to mention people automatically via GitHub policy without building or hosting our own issue subscriber system.

[JeffGarland]

@wusatosi Thanks for the clarification -- there's still some magic there with how the name gets translated to a list that I don't understand but no matter.

I suggest one of: core-reviewers, principal-reviewers, primary-reviewers, or key-reviewers.

[wusatosi]

There's still some magic there with how the name gets translated to a list that I don't understand but no matter.

So basically people in that file get notified when any PR opens up. If a team is included, everyone in the team also gets notified.

I suggest one of: core-reviewers, principal-reviewers, primary-reviewers, or key-reviewers.

I have no opinions on this, leads should make a call here.

[JeffGarland]

My preference is principal-reviewers. If no one has a strong feelings in the next few hours we should do it and move on. We can always revisit it later as we're not imposing a forever-name in an ISO standard here...

[neatudarius]

My preference is principal-reviewers. If no one has a strong feelings in the next few hours we should do it and move on. We can always revisit it later as we're not imposing a forever-name in an ISO standard here...

Suggestion applied.

It seems it wasn't enough time for this for agenda today (I skipped it, but added on agenda and required feedback).

@JeffGarland , can we move with your proposal? (Check actual content in the file) - cc: @bemanproject/leads