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

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.