Skip to content

New collaborator roles #712

Description

@jasnell

This week GitHub announced two new collaborator roles: triage and maintainer. As far as I know, these have not yet been enabled for our organization but they are coming and we should decide how to use them, if at all.

Triage (beta): Recommended for contributors who need to proactively manage issues and pull requests without write access

Maintain (beta): Recommended for project managers who need to manage the repository without access to sensitive or destructive actions

The Maintain roles includes all of the permissions of the write role and adds: editing repo description, managing topics, enabling/disabling wikis, and managing project boards. As such, I don't think it provides enough additional benefit for us to make use of it.

The Triage role adds the ability to label, close, or assign issues without giving full write access to the repo. This one, I think will be super useful and we should consider using it. We just need to determine how.

Activity

  1. targos commented on May 24, 2019

    @targos
    Member

    The permissions are enabled for the nodejs org:
    image

  2. richardlau commented on May 24, 2019

    @richardlau
    Member

    I'd suggest Triage could be helpful for projects that have restricted write access but could use help managing issues, e.g. build? cc @nodejs/build

  3. jasnell commented on May 24, 2019

    @jasnell
    MemberAuthor

    Ah, nice, that's new then. They weren't there yesterday when I checked.

  4. cjihrig commented on May 24, 2019

    @cjihrig
    Contributor

    Maybe we could create a new role in the project for people that are interested in helping triage issues, but not necessarily committing code. I can't remember specific examples off the top of my head, but I do recall people requesting that ability in the past. Or maybe emeriti could retain triage permissions.

  5. sam-github commented on May 24, 2019

    @sam-github
    Contributor

    I remember one person who was reluctant to become a collaborator, despite doing lots of useful work around docs and issues, out of fear of inadvertently messing something up. The triage role might have helped with that, but that person accepted collab nomination eventually.

    It's not clear to me that the triage role is useful to us. Managing another flavour of collab status seems overly bureaucratic. If we trust people to close issues I think we can trust them to not push code if they don't intend to, or to not use the github "edit in place" UI to modify code. Both of which would be reversible even if they did do it. I think the node.js collab spirit is more one of trusting in people to not be malicious, and knowing that we can fix things if a mistake is made (which is relatively infrequent, though I have personally rolled back master once blush).

    The only admin capability I ever envied was the ability to move issues between repos, specifically to the help repo. If that could be enabled for all collaborators, that would be pretty useful, IMO. Right now, I think only TSC (aka admin) members can do that.

    Myself, looking at the new roles, I'd be more tempted to use the new "Maintain" role by giving it to all collaborators, so that more people can help out with github maintenance.

  6. targos commented on May 24, 2019

    @targos
    Member

    The only admin capability I ever envied was the ability to move issues between repos, specifically to the help repo. If that could be enabled for all collaborators, that would be pretty useful, IMO. Right now, I think only TSC (aka admin) members can do that.

    Maybe if someone has the "Maintain" role for both nodejs/node and nodejs/help they are able to move issues? That would be awesome.

    Edit: I tried with another org and it's not possible.

  7. jasnell commented on May 24, 2019

    @jasnell
    MemberAuthor

    I believe moving issues is considered to be a "destructive" action and therefore limited to org owners.

  8. targos commented on Jun 2, 2019

    @targos
    Member

    Well, now everyone with write access to two repositories can move issues between them 🎉
    https://github.blog/changelog/2019-05-29-improvements-to-issue-transfer-permissions/

  9. mhdawson commented on Jul 31, 2019

    @mhdawson
    Member

    @jasnell is there anything more we should do on this?

  10. Trott commented on Aug 1, 2019

    @Trott
    Member

    I don't think there's anything to do here. Repositories that want/need this can use it or open requests in the admin repo to have an org Owner handle it for them. I think our current situation in the main repo is fine, at least for now. Anyone that has a proposal to change it can open an issue for discussion either here or in the main node repo.

    Closing, but feel free to comment or re-open if I'm being hasty with the "close" button.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions