Commit access after the first pull request #126
Comments
|
I'm in favor, obviously. 😁 |
|
I suggest that commits be merged by someone other than the author to allow for code review. This is specially important as a bad commit on master can break builds. |
|
@omeid I agree. We should make that clear in the CONTRIBUTING document and also look into GitHub's branch protection for master. |
|
Sounds pretty reasonable things to do! |
|
I enabled a few things:
If the tests past on a branch and it is up-to-date with master, it should still be possible to push its contents to master directly. It may or may not work with the "hub apply mail" workflow I've been using. Though I'd prefer squash merging, merge commits are also enabled for now. |
|
This whole idea could be impacted by what we end up doing for #136. |
|
Perhaps this policy should be documented in CONTRIBUTING.md. |
|
we should not require being able to run the test suite on all those platforms. CI should be doing that for us. |
|
Go to any open source project and you will invariably find a small group (or singular person) of regular contributors who fix random bugs, respond to issues, review PRs, etc. and a very long tail of people who contribute one or a few things, usually to fix some issue they were experiencing or adding some feature they wanted, and then never come back again. fsnotify is no different. There is nothing wrong with contributing just one fix or feature: I have a long list of projects where I've done exactly that. These are often the best kind of bug reports and feature requests: "I encountered this bug and oh, here's how to fix it", "I think this feature would be nice, so I added it". But do people really need commit access? Not so sure about that. You don't need commit access to contribute, and I don't really see the advantage of giving out commit access to one-time contributors. The issue I have is that I do think people need to be vetted to some degree; e.g. right now it's a bit unclear to me who can and can't push to the main branch for example (I can, not sure about others). Can people make a new release with a crypto miner (maybe "releasing" a new branch they created?) Dunno. You can set up protections and such, but it seems rather complex,cumbersome, and error-prone without any real advantages. I'm not overly paranoid about this, but you never know: people's accounts can get compromised, they can have a mental breakdown (e.g. that Aaron Swartz conspiracy repo, and the "block all Russians from using it"-repo), or whatnot. Furthermore, I'd like to be able to use @fsnotify/fsnotify to ping people for reviews and such, and pinging 36 people – some of whom probably have no interest in it – isn't too great. I pinged people here because just a "you've been removed from fsnotify" without context is probably a bit harsh. I wrote a small script to count some contributions of the current people with commit access; quite a few people last contributed years ago, or sometimes never at all. I went ahead and removed the commit access for anyone with an N, and retained it for people with Y, based on last activity + number of contributions. If anyone feels strongly that they should retain access then it can be restored, or if anyone wants to be removed then I can do that too (will prevent you from getting pinged on @fsnotify/fsnotify mentions).
|
|
That makes sense.
The icons didn't come through clearly. |
How boring; I changed it to "N" and "Y". That should work for everyone. |
|
sorry for I can't helped 😢 |
No need to apologise @zchee; everyone doesn't contribute to projects they use that need help (it would be impossible to do so, as there are too many!) |
|
Sure, I'll definitely review and merge any PRs @zchee! |
|
@arp242 Thanks, I'll try to implements without cgo :D |
Though I adopted Chris Howey's project and did some work on the API, fsnotify isn't "my project". It's a plumbing project to support other libraries that we rely on.
I've been fairly liberal with giving out commit access so far, but want to propose making it more official. That means updating the contributing document and me not being the only one to give out the commit bit. This particular policy I first saw @evanphx apply with Rubinius.
We do have all the git history distributed across multiple machines if somebody makes a mess, though that seems unlikely to happen after submitting a pull request that is merged.
What do you all think about this policy? Should there be any additional criteria? Is there a better approach?
The text was updated successfully, but these errors were encountered: