3 ms·

> Step 4: In frustration... Step 4 requires no frustration. It should be a relief you can fix it yourself rather than hope for some opaque engineering team to

by logn 10y ago

> Step 4: In frustration... Step 4 requires no frustration. It should be a relief you can fix it yourself rather than hope for some opaque engineering team to maybe fix it at some future date since your company doesn't have the Platinum Support package. > Steps 5..41: ... I think maintainers of small projects should do their best to merge whatever is given to them without back and forth or delay--just a prompt and sincere thanks. There's no reason to treat contributors like junior devs you're trying to teach and guide. Sometimes that requires swallowing some pride in having the code be just right or means you may want to fix up a few things after the merge.

tananaev 10y ago
As a maintainer of small project I would say that it depends. If the code is really useful and contributor is not willing to fix any of my comments, I would merge it anyway and fix it myself. If the code is so bad that it would be easier for me to completely re-write it myself, I would reject it. I'd like to think that my code review comments are reasonable most of the time, so it doesn't usually take more than 2 or 3 iterations to complete a pull request.
angry-hacker 10y ago
Yes. I remember when my first ever request was accepted. The fev thanked and with next release I saw he changed few things in my code, small things. Nevertheless it made me more comfortable submitting pull requests and really happy at the time.