Github user account settings and how we deal with those
I was looking at the people list in our Github the other day. There were some people that are not actively contributing to our projects, so I moved people around and removed some from the Outside Collaborator list. This provoked some comments. I decided to educate myself by reading documentation and thinking further how our we should organise our people and teams.
Github has pretty good documentation on how collaboration settings are handled, but there is a lot of material. I tried to collect the essentials here.
There are two major categories: Members and outside collaborators:
Members are, well members. I was trying to find a definition from Github documentation, but failed. Outside Collaborator is a person who isn’t explicitly a member of your organization, but who has Read, Write, or Admin permissions to one or more repositories in your organization. Outside Collaborator is like a member but with less power.
When Github members are in these two groups they can be managed in your peoject’s context. Accounts cannot be created, people need to be invited. You can group people into Teams, to given them uniform level of access via belonging into a certain team. Then there are roles. A person’s role in the organization defines their level of access in the organization.
There are also some other bits and bobs, like Owners and Billing Manager, granting fine grain access, etc.
Access management is life cycle management
By using these basic concepts you have the tools to manage people’s permissions in your project. It is a good idea to think how to organise people. Luckily it’s not rocket science, but if you start tweaking people’s accesses one by one you’ll soon lose track. One thing is that the permissions are not static. Access management is life cycle management. People come and go, they have different roles and drift from one team to another. One of the most overlooked aspect of this is when big change happens. When people leave, who is going to revoke their accesses? What is the procedure? Plan this, and you should be good.
Being open source, we wish that people find value in what we do and are willing to contribute. Core team’s role is to guide the development process and set rules and boundaries. These are always up to discussion but ultimately the core team decides what goes in and what comes out.
So how are we doing this at APInf? Here goes:
In github’s Members list you find APInf employees and those who are very tightly co-operating with APInf. These are basically people that are integral in orchestrating the operations. Outside collaborators are those who interact with us on regular basis. We treat these mechanisms are as access control ones, nothing else.
APInf platform project is an open source project. You can always raise an Issue or Pull Request. Here is a recent example. Jason from FIWARE helped us so that our README file complies with FIWARE rules:
The bottom line is that if you need access, we will grant it.
Contributing
Those who have contributed, we honor in our About section. This gets updated when we do a release.
If you want to participate, you can do many things. You don’t have to be able to code to help. You can test the SaaS, raise an issue via Github or waffle. If software is not your thing, give us a cheer, a clap or like our tweets.
It’s open source, contributions are welcome!
The writer is a product owner for APInf. APInf helps organizations to participate in API Economy, and we help APIs and Application developers with our API Management platform.
