paranormal
rain 🌦️If you're an open source maintainer, nothing makes new people happier than you taking their work, updating it with whatever changes you want to see happen, and landing it yourself. It's a much better experience than going back and forth with minor nits. (And give them credit for it!)
BTW I'm speaking from my own personal experience here. So much of my early open source experience was maintainers improving my terrible work and making it better, both through reviews and via fixing it themselves. To be honest I've never been in the position where they did something wrong—usually what the work was trying to do was pretty clear to everyone
Sophia J. Turner@rain I think this might vary by person. I've seen people complain when we've done this, so it's good to ask first.
Josh TriplettI've never seen someone complain about doing this for typos or clippy warnings or similar; the case I've encountered is "changed something that seems like a simple fix to you but that the submitter considers load-bearing for why they wrote the PR in the first place". (I've been in that situation on both sides, as a submitter and as a maintainer.)
+1 for "it's good to ask" in any case.
+1 for "it's good to ask" in any case.
Richard Schneeman@rain hard agree. I also like when someone makes heavy use of the “suggest” tool.
Shane Sveller@rain On the receiving end I would be totally fine with either treatment. Happy to have it merged at all, usually.
Devil's advocate: if they hoped to continue making more ongoing contributions, that elided dialogue around helping them land it themselves may have also helped them better internalize the standards and idioms of the project. At least, for the subjective pieces that can't just be critiqued accurately by CI or gleaned from any existing contributor guidelines.
@shane Depends, usually I'm talking after 1-2 rounds of reviews
Last substantial contribution I did this with, the contributor had done all the background research (thank you!) and 90% of the work, and it would simply be a waste of everyone's time to ask them to do things like change type and method names
L. David Baron@rain I think there can often be value in the back-and-forth as a teaching tool, though I think good maintainers can also sometimes tell when it's not desirable.
On the flip side, it's not great when the maintainer's edits make the patch completely wrong. I did once have a maintainer take a small patch I wrote, replace it with a completely different small patch that was incorrect, and land it with my name attached. (I think that may have been my only contribution to libX11.)
@dbaron Ah, that definitely sucks
Dan Mayer@rain I agree this can be an amazing experience and when you can and it is close try to do it.... but also if you are overwhelmed sometimes you can't and that is OK too... but if you help folks like this when they send a first PR you can make someone love open source for life like I do... cause someone helped me many times
@danmayer that is so great to hear! many of my own early experiences with open source were maintainers fixing up my patches too... I learned so much from that and was always grateful to them
cliffle@rain I'm enjoying Github's "allow edits by maintainers" feature on PRs for this. Being able to rebase and push additional commits to contributors' PR branches is great and saves the round trip.
Lukas Wirth@rain I do that quite frequently with rust-analyzer if I can tell it's gonna be a lot of back and forth rounds or just nitpicking changes from my side. Not like it invalidates their work if you adjust after their core/key changes!
Ghislain Vaillant@rain I definitely share your opinion, though I always prefer asking to avoid being perceived as rude.