summary: If you get tagged in a Github issue about Github Organization permissions, write us back telling us which repositories/organizations you want to retain write permissions to.

Good morning ROS Users,

A few months ago, Github announced major changes and improvements to Github organization permissions: https://github.com/blog/2064-new-organization-permissions-now-available


Many of the ROS Github organizations (those with “ros-” in the name) are still using legacy admin teams. We would like to migrate the legacy teams to the new organization permissions settings. We are also going to take this opportunity to audit the ROS organizations for ownership vs. membership permissions and inactive team members.


Some of our Github orgs have a very large number of owners, which is a security risk because ownership permissions allow owners to delete organizations, rename organizations, change billing information, or register OAuth tokens for external applications using the Github API. Limiting the number of owners is a way to mitigate that security risk. To that end, we will restrict the owners of the ROS Github orgs to core maintainers of those organizations, as well as the ROS team. We also want to limit the write permissions on these repositories to active committers to that repo.

This affects all ros* repositories on which the ROS team already has ownership access:

ros

ros-controls

ros-drivers

ros-drivers-gbp

ros-gbp

ros-geographic-info

ros-infrastructure

rosjava

ros-perception

ros-planning

ros-simulation

ros-teleop

ros-visualization

We are starting with ros and ros-gbp, which are the largest repos affected (most number of repositories and owners). We will be more strict about limiting owners on these repositories; in particular, because ros-gbp is for managing release metadata for other repositories, ownership will be limited to the ROS team at OSRF because we manage the buildfarm infrastructure. In ros-gbp we leverage Github teams to represent the ROS organization structure, and we can assign team admins to manage those individual teams.

One implication of removing owners from ros-gbp is that only the ROS team will be able to add new members to ros-gbp, which means we have to manually approve every new maintainer who has permissions to make releases. Luckily there is a way for team admins to give outside collaborators write access to individual repositories: https://help.github.com/articles/adding-outside-collaborators-to-repositories-in-your-organization/

We recommend using the collaborators mechanism if you need a release in a hurry, but we will also respond as quickly as possible to requests for adding new team members on ros-gbp.

If you are not currently active on a project and this audit reminds you that you would like to be more involved, you can always ask for write permission after showing a history of valuable contributions through pull requests. (For example, fixing issues for the upcoming Kinetic release is a great start :]) We encourage even core maintainers to use pull requests for peer review.

Next steps:
We will post issues on rosdistro for each ros Github org, tagging the current owners and asking if they would like to retain ownership permissions.
If you want to retain ownership, post on the ticket with a short justification why.
If you do not need to retain ownership, post on the ticket with the names of repositories for which you would like to retain admin or write permission. Otherwise we will decide for you based on your recent commit history.
If you do not respond 2 weeks after being tagged, you will be considered inactive and your ownership will be removed.

Regards,

The ROS Team