-
Notifications
You must be signed in to change notification settings - Fork 18
Refine language around "Collaborator"-ship #41
Comments
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. |
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.) |
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. |
Is it worth nailing down collaboratorship in the document on the off chance GitHub decides to redefine it on us? |
Having a formal definition of both "Collaborator" and "Contribution" definitely would not be a bad thing. |
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:
The text was updated successfully, but these errors were encountered: