ds-incubator: Share best practices in coding

2019-11-26: Access permissions for a GitHub organization

https://github.com/2DegreesInvesting/ds-incubator/issues/14

https://twitter.com/mauro_lepore

You want to propose changes to a source repo on a GitHub organization.

Set the usual plumbing (create_from_github()).
Initiate and work on your pull request (PR) (pr_init()).
Synchronize, push, and submit your PR (pr_sync(), pr_push()).

Fork source repo to your user account.
Create a local clone of your fork.
Connect your local clone with your fork (add remote origin).
Connect your local clone with the source repo (add remote upstream).

Create a local branch to host PR.
Change the local clone.
Commit informing what changed and why.

Synchronize the source repository to get the latest changes.
Push your PR to your fork.
Submit your PR from your fork to the source repo.

The set up involves too many steps.

Unless you do it systematically (e.g. with usethis) sooner or later you will forget some step.

For example, these are my most common mistakes:

I copy the wrong URL so remote origin points to the source repo instead of my fork.
I forget to create a new branch and add commits to my local master branch.

Your commit(s) are now in the PR branch of your fork.
Your commit(s) are now in the master branch of your fork.
Your commit(s) are now in the PR branch of the source repo.
Your commit(s) are now in the master branch of the source repo.
You fail to push and get an error.
It depends on your role and permission level:
- Roles: Owner, ..., member, collaborator.
- Permission levels: Admin, ..., push (write), read.

Organization members can have owner, billing manager, or member roles.

Owners have complete administrative access to your organization, while billing managers can manage billing settings. Member is the default role for everyone else.

You can set the default of what members can do for all repos.
You can manage access permissions for multiple members at a time with teams.
You can invite outside collaborators to give them access to specific repositories.

Read: Recommended for non-code contributors who want to view or discuss your project.
Triage: Recommended for contributors who need to proactively manage issues and PRs without write access.
Write: Recommended for contributors who actively push to your project.
Maintain: Recommended for project managers who need to manage the repository without access to sensitive or destructive actions.

...

Admin: Recommended for people who need full access to the project, including sensitive and destructive actions like managing security or deleting a repository.

Organization owners have admin permissions for every repository owned by the organization (table).