kcxtApr 10, 2024

hello kind sir/madam/friend,

thank you for reviewing my patch.

i notice that you have asked for a specific and simple change which improves consistency and readability. however, upon perusing the codebase, i noticed that there are similar places that don't have this change.

i am feeling rather lazy today, if i call you a clown, a fucking buffoon, will you let this one slide?

please explain to me in more words why i should make this simple change to my patch, lest i take my contributions elsewhere.

warmest regards,
bob

Show threadHaelwenn /элвэн/ Apr 10, 2024
@cas Reminds me of the few patches I've sent where they nit about indentation when the entire codebase is horribly inconsistent about it.
Show threadkcxt

@lanodan i think it depends on context. the exchange that inspired this toot didn't seem nit-picky to me.

i guess there isn't really an easy way to go about fixing a large codebase without coming across as nit-picky to some contributors. if you aren't strict about new code then you're just creating even more stuff you'll have to clean up later...

Apr 10, 2024 at 3:16amWeb
Show threadHaelwenn /элвэн/ Apr 10, 2024
@cas I think a good one is linking to tickets/MRs talking about such changes, or linking to some kind of guidelines/policies.

But also I think that when the nit isn't really about the code like indentation I think the maintainer should be able to take the patch and fix the nit, like they'd end up doing with regular maintenance anyway.
Show threadDenys F.Apr 10, 2024
@lanodan @cas my 5c(IMHO), i see all things case by case. Sometimes contributor bring really cool feature, spent lot of efforts, for such people i will disable all linters and fix their code later.
Sometimes project is in fast development state, and large contributions small issues can be ignored.
Otherwise, each project can only demand respecting short contributor guidelines, give reasonable suggestions for obvious mistakes, but nothing more.
I am wrong?