1. Cf-Bosh
  2. Topics

[project-leads] Proposal to change GH org permission structure for committers

Amit Kumar Gupta
 

Hi all,

1) People that aren't on the project teams have a hard time finding where work of that project team is actually happening.

Do you have any data on how significant a problem this is?  I assume 99% of a team's work happens in cf or cf-inc orgs, and forks are temporary in service of PR'ing to a repo in cf or cf-inc.  For teams I've worked on in the past, someone has forked into their personal account and given the rest of the team members collab access to that repo, then tore it down after the PR is merged.  Forking into a team account e.g. cf-routing also seems like it makes sense to solve this problem.  But the main point IMO is that almost all the team's work happens in a discoverable place (cf or cf-inc), and the work that happens on these forks is ephemeral and not meant to receive further upstream PRs, they exist to PR into something else downstream.

2) The team specific orgs are not typically setup to ensure CLA's for any inbound pull requests.

See prev comment about how these team-specific orgs are generally not used for long-lived work that should be receiving PRs.

3) Use of the cloudfoundry-incubator for these forks is confusing to observers, and completely different from what the incubator is supposed to be.

Agree that cf-inc shouldn't be used to house forks.  It's confusing, not the point of cf-inc, and doesn't scale (what happens when two teams want to fork nats into cf-inc?).

If there were a simple working agreement to do core work in cf or cf-inc, and use personal/team accounts/orgs for temporary forks for the purpose of PRs, would this solve the problems?

I would definitely be hesitant about wide-open push access across teams, I'd recommend allowing teams and people to organically choose the best cross-team collaboration workflow (cross-team pairing, PRs, direct commit) on a case-by-case basis.

Cheers,
Amit

On Wed, Dec 6, 2017 at 4:50 PM, Chip Childers <cchilders@...> wrote:
All (especially committers and project leads),

Some of the CFF project teams have been working in team specific GH orgs as a way to fork other project team repos that aren't core to their own efforts. Others have been using the cloudfoundry-incubator org for this same purpose. Largely, this seems to be happening inside of the Runtime PMC projects, but may be happening in other projects. Neither is optimal, for several reasons:

1) People that aren't on the project teams have a hard time finding where work of that project team is actually happening.
2) The team specific orgs are not typically setup to ensure CLA's for any inbound pull requests.
3) Use of the cloudfoundry-incubator for these forks is confusing to observers, and completely different from what the incubator is supposed to be.

Today, permissions are established for specific teams to access specific repos. In most cases they are limited to the repos owned by their project. In some cases, teams are already sharing commit rights to repos from other projects. The theory of locked down permissions is tied to the assumption of code ownership by one specific team.

I propose we change both the technical aspects of how permissions are handled, and the social / community aspect of how committers work with other project teams.

Specifically, I propose that we change our permission model to a much simpler one:

1) A single team for all committers in each PMC. That team would be given write permission across all repos that are part of projects in that PMC in both the cloudfoundry-incubator and cloudfoundry GH organizations.
2) All repos would also have a default branch selected and set as "protected" (disabling deletion and things like forced push).

This would both simplify some of the administrative work (much of which is handled by the awesome admin team at Pivotal today), and allow us to change our community's approach to cross project collaboration. Specifically, teams that want to make changes to another project's repo would create a branch in that repo to do their work in (and from which to do a PR). Project teams would still "own" their repos (and default branches), but this would be convention not enforced via permissions.

I welcome your thoughts and feedback on the proposal!

-chip
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815

--
You received this message because you are subscribed to the Google Groups "project-leads" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-leads+unsubscribe@cloudfoundry.org.
To post to this group, send email to project-leads@....
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/project-leads/CAD1Pwce90BMAZO1%3DdRES3gzAxvvT1onpw4uf%2BVQR-VqHRFpYAA%40mail.gmail.com.

1 - 1 of 1