3 ms·

This is one of the most uncharitable views I think you could take. You don't seem to have a nice thing to say about him. And have managed to pack a bit of negat

by roenxi 3y ago

This is one of the most uncharitable views I think you could take. You don't seem to have a nice thing to say about him. And have managed to pack a bit of negative insinuation in without any actual evidence or substance. Frankly, the dude is involved in cleaning up X.org code that is otherwise verging on unmaintainable. The appropriate response is a shrug and a "thanks". Backbiting is generally the wrong approach to attempted OSS contributions. If you have problems with his PRs go bring them up with him.

jcranmer 3y ago
There was a talk a long time ago (sorry, can't credit it) where the speaker pointed out that some contributors end up providing net negative value to the project: the value of their contributions is outweighed by the amount of time spent interacting with them in bug reports or the like. There are two reports in this thread of the contributor here derailing a conversation with something irrelevant. Another report is of him providing low benefit/high noise patches. If you start reading the mailing list posts linked up thread, his contributions to X.org seem to be veering in this direction too: the most recent idea is to... replace include guards with #pragma once. He was called out for this by the X.org maintainers (see https://lists.x.org/archives/xorg-devel/2024-February/059159.html https://lists.x.org/archives/xorg-devel/2024-February/059159...).
- kelnos 3y ago
  This bit from that reply covers a lot of how his changes felt to me: > Looking at this particular thing, what problem are you trying to solve? The existing header files already have the protection in place where it matters. And I don't expect why software that's mostly just in maintenance mode would see a lot of new header files being added. Quite a few of his changes seemed to me to have the motivation of "I like it better this way and think you should adopt my sense of taste". If you expressed interest in becoming a maintainer of one of our not-so-well-maintained components, then sure, go nuts. But changing a bunch of stuff to your style in code that I have to continue to maintain? No thanks. It wasn't all like this; one MR I recall changed the names of a bunch of constants so they'd be consistent with each other and what they were for (e.g. prefixing things in a certain way depending on if they were configuration key names, default values, etc.). That I do think was useful. Unfortunately I think that particular MR ended up not working out, because he never talked to me about his ideas in the first place, and I had a branch I'd been working on for a few weeks that, when merged, made his work full of merge conflicts and ultimately not as necessary anymore. And that was part of the issue: if he would have discussed the changes with me beforehand, I would have said "sure, that sounds useful, but you might want to wait a week or so until I merge this feature branch, which is going to change a lot of the code you're going to touch". But... nope, he wanted to lone-ranger it.
kelnos 3y ago
Maybe don't criticize without knowing the full situation, eh? Your uninformed, holier-than-thou attempt at dressing me down isn't particularly useful. Guy was a pain on the mailing list (and occasionally on IRC, too), nagging for code reviews and merges, against a team of part-time volunteers. He'd open many merge requests in a short time span, most of them changing a fair bit of code, some doing some mid-sized refactoring. Very rarely would he discuss his changes with the maintainers before making them. And when someone disagreed with his approach, he'd get testy and push his point of view harder. Not a team player, not someone I'd ever want to work with, whether on a volunteer open source project or in a professional paid work setting. > The appropriate response is a shrug and a "thanks". Not if the contributions (and interactions with the contributor) create a lot of make-work for the maintainers where the benefit is unclear or known to be fairly low. I'm certainly not going to thank someone for creating more work for me that doesn't need to be done. > If you have problems with his PRs go bring them up with him. The problems were mostly "this doesn't need to be done, and you're changing the code from something I already know to something I don't, and I'm the one who has to navigate and maintain it, so this will be a net negative to me". And yet... the MRs kept coming. I'm not going to claim the existing code is the best code in the world; some of my parts were written by me 15-20 years ago when I was fairly junior, and it could use some improvement. But going in and changing things without first talking to a maintainer is not the way to do it. Don't get me wrong, some MRs ended up getting merged. Some of the maintainers did think that some of them were useful. But it felt like sorting through all of it to figure out what was actually useful, was more effort than it was worth.
- roenxi 3y ago
  If he's causing you stress migraines over in Xfce land, go ban him over there. You're wasting your time trying to convince me you don't like his work, and you're still not going with evidence or substance of a problem. Some people raise a lot of PRs. > Maybe don't criticize without knowing the full situation, eh? Your uninformed, holier-than-thou attempt at dressing me down isn't particularly useful. My key complaint, you'll note, is that you aren't providing any details of the full situation and those that you are providing are uncharitable takes. I mean, you're being nasty to the dude and your complaint seems to be he isn't a senior dev. Fair enough. If you only want to review PRs by senior devs, warn the fellow then block him [0]. Don't go with public shaming as a strategy; HN is a big forum forum, the dude isn't here and he's presumably working under his real name. If you want to be mean because he's done something go ahead. But unless you're going to say he's actually done something bad, I'm going to note you're being mean without a complaint and that is poor form. > And when someone disagreed with his approach, he'd get testy and push his point of view harder. I can't pass that by without noting some irony, given the comment it is in context of. Software devs are known for this. [0] I speak loosely. Mr Lots of PRs could be anyone for all I know.

by roenxi 3y ago

jcranmer 3y ago

There was a talk a long time ago (sorry, can't credit it) where the speaker pointed out that some contributors end up providing net negative value to the project: the value of their contributions is outweighed by the amount of time spent interacting with them in bug reports or the like. There are two reports in this thread of the contributor here derailing a conversation with something irrelevant. Another report is of him providing low benefit/high noise patches. If you start reading the mailing list posts linked up thread, his contributions to X.org seem to be veering in this direction too: the most recent idea is to... replace include guards with #pragma once. He was called out for this by the X.org maintainers (see https://lists.x.org/archives/xorg-devel/2024-February/059159.html https://lists.x.org/archives/xorg-devel/2024-February/059159...).

kelnos 3y ago
This bit from that reply covers a lot of how his changes felt to me: > Looking at this particular thing, what problem are you trying to solve? The existing header files already have the protection in place where it matters. And I don't expect why software that's mostly just in maintenance mode would see a lot of new header files being added. Quite a few of his changes seemed to me to have the motivation of "I like it better this way and think you should adopt my sense of taste". If you expressed interest in becoming a maintainer of one of our not-so-well-maintained components, then sure, go nuts. But changing a bunch of stuff to your style in code that I have to continue to maintain? No thanks. It wasn't all like this; one MR I recall changed the names of a bunch of constants so they'd be consistent with each other and what they were for (e.g. prefixing things in a certain way depending on if they were configuration key names, default values, etc.). That I do think was useful. Unfortunately I think that particular MR ended up not working out, because he never talked to me about his ideas in the first place, and I had a branch I'd been working on for a few weeks that, when merged, made his work full of merge conflicts and ultimately not as necessary anymore. And that was part of the issue: if he would have discussed the changes with me beforehand, I would have said "sure, that sounds useful, but you might want to wait a week or so until I merge this feature branch, which is going to change a lot of the code you're going to touch". But... nope, he wanted to lone-ranger it.

kelnos 3y ago

Maybe don't criticize without knowing the full situation, eh? Your uninformed, holier-than-thou attempt at dressing me down isn't particularly useful. Guy was a pain on the mailing list (and occasionally on IRC, too), nagging for code reviews and merges, against a team of part-time volunteers. He'd open many merge requests in a short time span, most of them changing a fair bit of code, some doing some mid-sized refactoring. Very rarely would he discuss his changes with the maintainers before making them. And when someone disagreed with his approach, he'd get testy and push his point of view harder. Not a team player, not someone I'd ever want to work with, whether on a volunteer open source project or in a professional paid work setting. > The appropriate response is a shrug and a "thanks". Not if the contributions (and interactions with the contributor) create a lot of make-work for the maintainers where the benefit is unclear or known to be fairly low. I'm certainly not going to thank someone for creating more work for me that doesn't need to be done. > If you have problems with his PRs go bring them up with him. The problems were mostly "this doesn't need to be done, and you're changing the code from something I already know to something I don't, and I'm the one who has to navigate and maintain it, so this will be a net negative to me". And yet... the MRs kept coming. I'm not going to claim the existing code is the best code in the world; some of my parts were written by me 15-20 years ago when I was fairly junior, and it could use some improvement. But going in and changing things without first talking to a maintainer is not the way to do it. Don't get me wrong, some MRs ended up getting merged. Some of the maintainers did think that some of them were useful. But it felt like sorting through all of it to figure out what was actually useful, was more effort than it was worth.

roenxi 3y ago
If he's causing you stress migraines over in Xfce land, go ban him over there. You're wasting your time trying to convince me you don't like his work, and you're still not going with evidence or substance of a problem. Some people raise a lot of PRs. > Maybe don't criticize without knowing the full situation, eh? Your uninformed, holier-than-thou attempt at dressing me down isn't particularly useful. My key complaint, you'll note, is that you aren't providing any details of the full situation and those that you are providing are uncharitable takes. I mean, you're being nasty to the dude and your complaint seems to be he isn't a senior dev. Fair enough. If you only want to review PRs by senior devs, warn the fellow then block him [0]. Don't go with public shaming as a strategy; HN is a big forum forum, the dude isn't here and he's presumably working under his real name. If you want to be mean because he's done something go ahead. But unless you're going to say he's actually done something bad, I'm going to note you're being mean without a complaint and that is poor form. > And when someone disagreed with his approach, he'd get testy and push his point of view harder. I can't pass that by without noting some irony, given the comment it is in context of. Software devs are known for this. [0] I speak loosely. Mr Lots of PRs could be anyone for all I know.