4 ms·

Exactly 0 people are maintainers of projects they don't have commit access to. Even if they dip after 6 month it's far better to have the option to remove any

by casey2 3y ago

Exactly 0 people are maintainers of projects they don't have commit access to. Even if they dip after 6 month it's far better to have the option to remove any of the 6 months worth of commits in the current codebase than to hypothesis about the state of a future codebase/environment 6 months ago. This becomes even easier with good commit messages. If somebody is a user and decides to write a pull request, they are already invested anything more is virtue signaling, no amount of which will guarantee that they will be there in years, which is an unreasonable stipulation for a project that could be obsolete yesterday.

danielheath 3y ago
When they dip 6 months time, you’re maintaining whatever strange crap they let into your project. If they offer to maintain it, I’d sooner point my docs to suggest using their fork instead of my repo. That makes them the maintainer without me offering to support what they do
em-bee 3y ago
removing code that is not dead, but because it is bad quality is about the hardest thing to do. because if i had time to clean up the code, i could have done it when the pull request was made. so i prefer to gatekeep and not let in bad code to begin with. if it is an application i depend on, then i need to trust the the code to be good enough. mistakes are ok, i make them too. but giving someone commit rights and then finding out 6 months later that almost everything they committed was not good sounds like a bad idea. i also believe that code should be reviewed by a second person, if possible. so if i have a one-man project and there is a second contributor, i would review their pull-requests and commit them. if they in turn are able and willing to review my commits, i might give them commit rights as long as we both can agree to review each others commits. in that case, the other person will only commit code i have written, and i will commit code they have written. (or however we set up the process. either way i will still have seen all the code going into the project.) but i agree with the article. it really depends on the nature of the project. i do have some projects where i am just messing around, creating something useful, but not critical. having others directly commit to that would probably not be a big problem, even if the code they write is messy, as long as it works, it'll be ok. alternatively, if i do have the time to review code, i can also do that after it has been committed. if it's bad, i can clean it up then. and if there is to much cleanup work happening i can revoke commit rights and i'll only have to remove the most recent commits that i don't have the time to clean up.
unshavedyak 3y ago
> If somebody is a user and decides to write a pull request, they are already invested anything more is virtue signaling, no amount of which will guarantee that they will be there in years, which is an unreasonable stipulation for a project that could be obsolete yesterday. I'll believe that when they're replying to issues, labeling bug reports, etc. Hell, or even making PRs that maintain the code base! That would be an instant commit access. Writing new code is easy. Maintaining is tough, boring, etc. Again, if i even get a gut feeling that this is going to be work - i'd rather just fork my own damn project and give them my old one. I FOSS projects to let others use my work if it's of value to them. It's a thin line between having fun side projects and work. I think you misunderstand the type of projects i FOSS. If your arguments were common i'd be more inclined to just make projects private, as i'm that averse to wanting more work in life. I really, really like to keep the fun in my projects.
- em-bee 3y ago
  replying to issues, labeling bug reports, etc i do that on projects that i am interested in. because it sometimes is a good way to get into a project and show that i care about the project as a whole, not just getting my patch accepted. and why should i not care? i am using it myself. to call that virtue signaling as the grand parent comment does, is frankly insulting. however, caring about a project doesn't guarantee anything. a while ago i found a nice project that solved a problem i had. it had some bugs that i fixed to make it work for me. i shared the issues and fixes with the project, expecting to do more work later. but then my situation changed and this project is no longer a priority. i hope to get back to the it, but i can't say when that will be. i still care about the project, i just don't have time for it now.

by casey2 3y ago

danielheath 3y ago

When they dip 6 months time, you’re maintaining whatever strange crap they let into your project. If they offer to maintain it, I’d sooner point my docs to suggest using their fork instead of my repo. That makes them the maintainer without me offering to support what they do

em-bee 3y ago

removing code that is not dead, but because it is bad quality is about the hardest thing to do. because if i had time to clean up the code, i could have done it when the pull request was made. so i prefer to gatekeep and not let in bad code to begin with. if it is an application i depend on, then i need to trust the the code to be good enough. mistakes are ok, i make them too. but giving someone commit rights and then finding out 6 months later that almost everything they committed was not good sounds like a bad idea. i also believe that code should be reviewed by a second person, if possible. so if i have a one-man project and there is a second contributor, i would review their pull-requests and commit them. if they in turn are able and willing to review my commits, i might give them commit rights as long as we both can agree to review each others commits. in that case, the other person will only commit code i have written, and i will commit code they have written. (or however we set up the process. either way i will still have seen all the code going into the project.) but i agree with the article. it really depends on the nature of the project. i do have some projects where i am just messing around, creating something useful, but not critical. having others directly commit to that would probably not be a big problem, even if the code they write is messy, as long as it works, it'll be ok. alternatively, if i do have the time to review code, i can also do that after it has been committed. if it's bad, i can clean it up then. and if there is to much cleanup work happening i can revoke commit rights and i'll only have to remove the most recent commits that i don't have the time to clean up.

unshavedyak 3y ago

> If somebody is a user and decides to write a pull request, they are already invested anything more is virtue signaling, no amount of which will guarantee that they will be there in years, which is an unreasonable stipulation for a project that could be obsolete yesterday. I'll believe that when they're replying to issues, labeling bug reports, etc. Hell, or even making PRs that maintain the code base! That would be an instant commit access. Writing new code is easy. Maintaining is tough, boring, etc. Again, if i even get a gut feeling that this is going to be work - i'd rather just fork my own damn project and give them my old one. I FOSS projects to let others use my work if it's of value to them. It's a thin line between having fun side projects and work. I think you misunderstand the type of projects i FOSS. If your arguments were common i'd be more inclined to just make projects private, as i'm that averse to wanting more work in life. I really, really like to keep the fun in my projects.

em-bee 3y ago
replying to issues, labeling bug reports, etc i do that on projects that i am interested in. because it sometimes is a good way to get into a project and show that i care about the project as a whole, not just getting my patch accepted. and why should i not care? i am using it myself. to call that virtue signaling as the grand parent comment does, is frankly insulting. however, caring about a project doesn't guarantee anything. a while ago i found a nice project that solved a problem i had. it had some bugs that i fixed to make it work for me. i shared the issues and fixes with the project, expecting to do more work later. but then my situation changed and this project is no longer a priority. i hope to get back to the it, but i can't say when that will be. i still care about the project, i just don't have time for it now.