[ros-users] ROS Github Organization Permissions Audit

[Jackie Kay]

*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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20160418/bb0b17b0/attachment.html>