IEEE.org     |     IEEE Xplore Digital Library     |     IEEE Standards     |     IEEE Spectrum     |     More Sites

Commit a2908168 authored by Beth Hancock's avatar Beth Hancock 🌿
Browse files

Update gitlab-participant-roles-and-access.md

parent ced48edb
......@@ -12,24 +12,21 @@ For each of the above roles we need to answer the following questions:
* Do we need to create workarounds to allow people to make their contributions?
* What are those?
The Community Badging Group has been working on [some descriptions](https://opensource.ieee.org/community-advisory-group/community-badging/meetings/-/blob/proposed/Supporting%20Documentation/Meeting-role-responsibilities.md) for a couple of these roles. These may be beneficial to us.
The Community Badging Group has been working on [some descriptions](https://opensource.ieee.org/community-advisory-group/community-badging/meetings/-/blob/proposed/Supporting%20Documentation/Meeting-role-responsibilities.md) for a couple of these roles. These may be beneficial to this process.
Participants have different abilities depending on the access level they have in a particular group or project and on the type of subgroup or project. If a participant is both in a project’s group and the project itself, the highest permission level is used.
Take care when granting permission to the primary group (in the case of IEEE SA OPEN community groups, these are those that start with a three digit number), as those permissions will apply to all subgroups and projects contained in the main group. This also applies to any project contained in a subgroup (including Meetings and About).
**Permissions in GitLab**
For reference here are the general outlines of what each permission
_Guests_ (and anyone with access to the site) can add issues, comment on issues and close issues that they have opened.
_Reporters_ can add and assign issues, as well as change the location of issues on boards. They can also pull code and create merge requests (aka request changes to the content). Until the participant is familiar with the regular practices for contribution, this is the highest level of access that should be granted to a new participant.
_Reporters_ can add and assign issues, as well as change the location of issues on boards. They can also pull code and create merge requests (aka request changes to the content).
_Developers_ can remove files, delete licenses and various other things that could cause difficulties. They must do so via a merge request, so those changes are reversible once noted. A participant should be granted this level of access if they are actively working on the project and familiar with the process.
Great care should be given in granting _Maintainer_ status as this role allows the participant to grant access to the group, enable/disable branch protection, push to protected branches, delete wiki pages, and manage Pages (external static sites). This level of access to a group or subgroup might be granted to a facilitator or other leadership.
The _Maintainer_ role allows the participant to grant access to the group, enable/disable branch protection, push to protected branches, delete wiki pages, and manage Pages (external static sites). This level of access to a group or subgroup might be granted to a facilitator or other leader.
_Owner_ status of numbered groups and subgroups is currently restricted to staff participants.
**Changing Participant Role**
If a participant is not active in a group, subgroup or project in which they have a role above Guest for four months, their permissions will be reduced to Guest. An email is automatically sent to the user to inform them of this change in permissions.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment