tikv/community

Update authentication mechanism

tisonkun opened this issue · 8 comments

subtask of #118

Since our permissions are flatten into repository level. @hi-rustin and I tend to use GitHub team to maintain the permission and leave the bot simply respect GitHub permission.

ti-chi-bot can apply such rules according to this page

use_github_permission: Use GitHub permissions and have write and admin collaborators as reviewers and committers

And for repositories where bot is not configured (bot has a limit on events received), the model retains.

I propose that we refine the permissions to:

  1. triage -> can approve (reviewers)
  2. write above -> can apporve and merge (committers and maintainers)

This way we can have more permissions control. Now we have people above write permission as both reviewers and committers, so it is not possible to distinguish reviewer and committer permissions very well.

What do you think?

(bot has a limit on events received),

Some details: the limitation in this place is the API rate limit; the bot can accept all events, but can't respond on so many repositories because GitHub has strict limitations on API usage.

the model retains.

More details: Some of our repositories that do not have particularly many collaborators do not really need to use bots (it will bring the cost of learning and use). So if we use the GitHub teams permissions model, we can work with bots on larger repositories and use GitHub permissions directly on smaller repositories.

the model retains.

More details: Some of our repositories that do not have particularly many collaborators do not really need to use bots (it will bring the cost of learning and use). So if we use the GitHub teams permissions model, we can work with bots on larger repositories and use GitHub permissions directly on smaller repositories.

Yes. And then rust-prometheus works well as is. But still I'd like to reach out them for a consistent view.

I propose that we refine the permissions to:

  1. triage -> can approve (reviewers)
  2. write above -> can apporve and merge (committers and maintainers)

This way we can have more permissions control. Now we have people above write permission as both reviewers and committers, so it is not possible to distinguish reviewer and committer permissions very well.

What do you think?

That makes sense to me.

Thanks to @hi-rustin 's excellent work ti-community-infra/tichi#597 and with the consensus reached at #122 we are going to apply the change of community governance in days.

Closed as implemented. You can still comment if there is any bad case found.