Reconstitute the Readium github teams to reflect the changed approach

[rkwright]

The current set of github teams is quite antiquated, dating back to 2012. Given the changes in emphasis and architecture, it probably makes sense to restructure the teams
In addition, the existing team members generally have commit privileges, which tends to run counter to out direction today of using pull-requests
So one option is to create a new set of teams (and delete the old ones).

Laurent has proposed the following set of teams:

• Readium SDK Contributors
• Readium JS Contributors
• Readium Mobile iOS Contributors
• Readium Mobile Android Contributors
• Readium Desktop Contributors
• Readium Web Contributors
• Readium LCP Server Contributors
• Readium Architecture

Each member of these teams would have write (commit) access to the appropriate repo(s).

Questions:

• What problem are we trying to solve? Inadvertent or malicious or confused commits have never been a problem AFAIK. Not to say this isn't a good idea, but what problem are we solving?
• Do we really want all members of a team to have commit privileges, or only one or two members have the privileges to approve pull-requests and merge them? If so, what is the point of the team?
• How do we keep track of all this? WHO keeps track of all this?

[JayPanoz]

Very quick question: where does ReadiumCSS fit?

As far as I can tell, I’m the only collaborator (at least in the settings’ list), but I know others like Laurent and Hadrien can modify the repo as well.

(Sorry for being the edge case)

[rkwright]

@JayPanoz No worries. Just an oversight. I would assume that ReadiumCSS would be its own "team" but we can discuss that tomorrow. It sort of comes back to my second question above.

[rkwright]

Some useful links: https://help.github.com/articles/about-teams/

BTW, I just noticed that for some reason (lost in the mists of time), the original "contributor" teams (JS and SDK) are both "secret" ?! Obviously, that should be fixed as part of the revamping.

[danielweck]

Suggestion: disable git push --force.

"Protect matching branches - Disables force-pushes to all matching branches and prevents them from being deleted. "
https://help.github.com/articles/enabling-branch-restrictions/

Additional info (enterprise GitHub):
https://help.github.com/enterprise/2.16/admin/guides/developer-workflow/blocking-force-pushes-to-a-repository/

[rkwright]

From @llemeurfr 👍
I confess I would have a more basic approach, where people who are not "committers" (PR reviewers) don't even create branches in the Readium space, but create them on their own space and propose PRs on the develop branch of a given repo.
Which IMO simplifies the configuration, a you just have to affect Teams to repos with write access (and don't hae to create rules as in ...
Then in each of the repos I created a pair of new rules, one each for master and develop and set the “team” as the only ones allowed to push changes to those branches
For which reason would people be able to push changes to "feature" branches they don't have the right to create, on this Readium space?