Policy: Adding users to the organization

[whoabuddy]

Comment from @SomeMoosery on PR #2:

I think at a certain point it gets excessive continuously adding people as members, which is a future conversation, but maybe should shouldn't keep doing going forward. Thoughts?

I wasn't sure how to answer this, but I do know that Github has several advanced features for managing orgs/teams, and we should look further into this.

Resources

• Walkthrough: How to set up a Github organization and team
• Github Help: Managing people's access to your organization with roles
• Github Help: Organizing members into teams
• Github Help: Managing access to your organization's repositories
• Github Help: Managing access to your organization’s project boards
• Github Help: Keeping your organization secure

[whoabuddy]

Based on some additional reading, I propose we break up the teams based on the leads we have now, and set up a default flow for permissions such that:

1. By default, anyone can contribute to the organization with or without being a member of it, and we continue to encourage people to fork the repo and submit a PR with changes.
2. If someone wants to join the organization, the default access level is Read, and they are still encouraged to fork the repo and submit changes via PR. (this would be unlikely, though, based on 3 below)
3. If someone introduces themselves in Discord and joins a team, the team leader should add them to the organization and to the same team in Github. The user can request access to teams as well, but the team leader would need to approve it.
4. The team leader should send an onboarding message to the user (based on a template), or point the user to the pinned information in Discord for getting started.

That way we are getting the most out of using Discord and Github together, as well as creating a hierarchy that is simple yet could be further split down the road if needed. The more places we can point to somewhere consistent for information, and the more we pay attention the flow of a contributor, the better we can encourage people in this process.

Based on the groups in Discord now, the proposed Github Teams structure would be as follows, and would allow for us to at-mention groups from issues or wherever, and we can mirror the structure in Discord for easier communication.

Team Name	Team Lead	Team Description
Admins	Anthony / Carter	rights to create/manage repos, create/manage teams
Maintainers	Carter	rights to approve/merge changes
Front End	Adham	working with the front end of the application
Back End	Carter	working with the back end / server side of the application
Hardware	Akil	working with panflute hardware
Design UX UI	Brian	working with design, wireframes, social
Translations	Sal	working with translations
Analytics	Nick	working with analytics
Documentation	Jason	working with documentation or gh-pages

There were a few teams I left out because I wasn't sure how they would apply to Github, e.g. Marketing, Legal, and Growth - but if someone else needs to be added it would be easy enough to create a new team and follow the same template/idea.

[ngiangre]

Love it! As long as there's a good mechanism for inter-team communication. Especially for promoting continuous integration from our education/health/translations content to the app development and UI. What are some action items moving forward with this or looking more into it first?

[whoabuddy]

This should be easy enough to implement if we agree on a structure like the one above, the biggest challenge for me is knowing who needs to sign off on the idea, who to add where outside of what I listed, or if I am missing any groups or ideas from the big picture side of things.

It will be important to document this process and the permissions along the way. I think it will naturally grow into operating procedures for the organization, and we can use this as an opportunity to make sure our lists like this one in SUPPORT.md are up to date.

Communications-wise we would gain the ability to at-mention a team on Github, and it would provide a structure for managing a team kanban board like @awu556 mentioned in the Discord chat.

There are other things that can be built in as we go along, but starting simple is always the best!

[awu556]

For sure! I wish there was a way to do global dashboard for either Github or Discord to show a high level overview of what each team was working on for the week i.e. someone from analytics could hop over to front end, and see they were focusing on a certain component or the frontpage for the week, and vice versa. Just eliminates the need for digging through Discord chats or Github issues to find the info you need at a glance.

[AdhamAH]

That looks good! one question, Maintainers are only @SomeMoosery ?

[whoabuddy]

@AdhamAH that's up to the group to decide, I know @SomeMoosery is the main one approving PRs right now, but I also saw some mention on Discord about branch protection and a code owners file. I think we are aiming for two approvals per PR so there would have to be more - this issue is a great place to propose other people for roles if you have any in mind.

[acthelemann]

I can't say who should own what for other parts of the organization, but I would say @AdhamAH, @SomeMoosery, and I should be code owners for Corona-tracker/client/, and @SomeMoosery and I should be code owners for Coronalert.

For now, I'm going to submit a PR for code owners for what I just mentioned and also add some branch protect rules for master for those two repos.