Skip to content
This repository has been archived by the owner on Apr 18, 2018. It is now read-only.

Refine language around "Collaborator"-ship #41

Closed
chrisdickinson opened this issue Apr 9, 2015 · 5 comments
Closed

Refine language around "Collaborator"-ship #41

chrisdickinson opened this issue Apr 9, 2015 · 5 comments

Comments

@chrisdickinson
Copy link

Per @trevnorris from the meeting: right now we define collaborators one-to-one with Github's definition of collaborators – that is, even if we're adding folks solely to work on the issue tracker, they also receive the commit bit, though they may not have been given the go-ahead to land commits.

Should we refine this language such that there are different levels of collaboratorship? At present in io.js there are roughly four groups:

  • Non-collaborators: community members who use io.js and interact with it over the issue tracker.
  • Collaborators: community members who are entrusted with reviewing & landing changes, handling the issue tracker, and proposing releases.
  • Release Managers: Collaborators who have the additional ability to cut releases.
  • TC members: Collaborators who have the ability to bring contentious items to a vote (roughly speaking.)
@Fishrock123
Copy link
Member

I'm not sure there should be any separation. Concerns just about code are often magnified too much.

In short: Git is recoverable. The issue trackers we use are not, and people's impressions also less so.

@chrisdickinson
Copy link
Author

For the record, I'm pretty strongly in favor of limiting the roles of the project to the four defined above.

Even if GitHub were to introduce a "issue-management-only" role, I'm not sure I would be in favor of adding a role for that. Trusting new collaborators with the commit bit gives them ownership of the project, and it makes it more likely that they will be repeat contributors.

(And as @Fishrock123 notes, we're in a position where the tools we use preclude permanent damage being done to the project.)

@jasnell
Copy link
Member

jasnell commented Apr 9, 2015

I tend to agree. Having the commit bit set is not so much a problem given the additional process we have in place (or will have in place) and things are fairly simple to undo (including revoking the commit bit if necessary). I'd much rather keep the playing field as level as possible with the fewest levels.

@chrisdickinson
Copy link
Author

Is it worth nailing down collaboratorship in the document on the off chance GitHub decides to redefine it on us?

@jasnell
Copy link
Member

jasnell commented Apr 9, 2015

Having a formal definition of both "Collaborator" and "Contribution" definitely would not be a bad thing.

@jasnell jasnell closed this as completed Mar 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants