Suggest GH team setup for access control

[patcon]

I just kinda decided to use a lieutenant model like the linux project, which seemed simple given my experience. But I could imagine this part being much more confusing if a group didn't have an opinion on a way to manage access -- a GH team, done incorrectly, can in effect lock participants out of being able to work effectively, and so kill later momentum in the project.

How I operated:

• Created a single "Lieutenant" team, with admin access on each repo -- the repos were added to that team whenever a member transferred the repo from their personal account to the org account.
• whichever 1 or 2 people were managing that account before (or who wanted to take ownership), they were added to the lieutenant team.
• @jpmckinney gently urged people in chat to set their team membership to "public", so that the public org page appears active and participatory: https://github.com/orgs/edgi-govdata-archiving/people/patcon
• Added all participants as general "People" to team org. This ensured we stayed connected to the github accounts of participants. This also allows the org to decide what catch-all access they wanted to offer -- we set it to "read" access on all repos, but could later choose to permit "write" access: https://github.com/organizations/edgi-govdata-archiving/settings/member_privileges (this could be chaotic, so I think "read" is the correct choice)
• During hackathon, gently reminded people to accept the team invite -- easy to dismiss as spam after the event.

Anyhow, hopefully that helps somehow. Lemme know if there's a better place for me to drop it.

[dcwalk]

This is great @patcon! We've added into the Recommendations and Lessons Learned section and pointed to this issue for the full explanation. I'm closing this but it'll still be linked to!