"[…] Instead of accepting my [#LinuxKernel] patch or guiding me towards a better solution, he went ahead and implemented his own fix, giving me credit only for reporting the issue […]

My first contribution to the [#Linux] #kernel was a really frustrating and discouraging experience, dealing with people who do not think it’s important to get proper recognition for your work. […]"

https://ariel-miculas.github.io/How-I-got-robbed-of-my-first-kernel-contribution/

1/ Side note: I sometimes wonder if…

2/…patches from new or rare contributors should have some kind of tag to indicate things like

(1) I have no interest in learning how to do things better, I just want it fixed; I'm thus happy if someone dramatically changes the patch or writes a better one.

(2) I'd really like to learn how to do this properly, hence would be grateful if someone could guide me somewhat.

Why? Well, misunderstandings here can be annoying and a waste of time for both sides (and lead to situations like the above).

@kernellogger to the author: it's going to be better once your let your ego dissolve a little, trust me

@lkundrak

Well, up to a point I agree, but OTOH I can understand the authors point view up to a point, too.

It's complicated.

@kernellogger i think everybody goes through this sort of thing
i only meant to say the impedance mismatch between someone who's 100% in for the credit and someone who doesn't understand why would someone care about leaving a footprint in wet concrete is going to shrink over time :)

@lkundrak @kernellogger I've learned it's better to take an imperfect fix from a new contributor than it is to rewrite their patch for them. That, more than anything else, inspires them to keep coming back.

@Conan_Kudo @kernellogger pro tip:
if you think all your patches are shit, you're never going to be upset about somebody not applying them

@Conan_Kudo @lkundrak

I kinda agree when it's your own project, but Linux is a collaboration project – hence applying a patch might not be an option, as someone higher up maintainer (e.g. Linus) might then yell a you

@kernellogger @Conan_Kudo yes. questionable patches in git history are not great for e.g. bisecting.

In NM we'd have figured out that people are more motivated to come back and contribute more (fixes or bug reports) when they've been properly credited (Author:, Suggested-by, Reported-by:). Perhaps then they identify more with the project and feel responsible :)

We'd try to preserve the Author: tags no matter how large were the changes we made to the tag, but ended up explaining the changes in the commit messages: [lkundrak@...: replaced tabs with spaces and spaces with vertical tabs, also rewrote in C#]

I thought this was a fairly common practice at least for smaller fixups, we certainly saw this elsewhere, perhaps it was even in kernel?

@lkundrak @kernellogger `Co-authored-by:` is a great tag for situations like this. I don't see it super-often in the kernel though.

@Conan_Kudo @lkundrak

It's "Co-developed-by:" in Linux:

$ git log origin/master --grep 'Co-developed-by:' --since="1 year ago" | grep 'Co-developed-by:' | wc -l
1312

$ git log origin/master --grep 'Co-developed-by:' --since="1 year ago" --oneline | wc -l
1028

@lkundrak @kernellogger That's IMO a very sad take, sir!

Obviously, we don't know how bad the commit was, nor how much time pressure the maintainer was under..., but his answer to being asked to be able to iterate on the patch until it is ready to land wasn't acceptable.

Not only did he reject a capable potential new contributor (hard to justify more of this work if he can't get credit for it), but the way he justified not working with the contributor amounted to: I'm the king here.

@lkundrak @kernellogger you can justify this behaviour by saying he is responsible for his subsystem's quality and maintainability, but what I see is that this subsystem has a maintainer who is not a team player.

I doubt this would be a power grab, and I'm sure he has the best intentions at heart... but the reality is that he is setting himself up for burning out:

* Feel responsible for everything
* See problems mounting up
* Reject help to fix things faster
* Fail to deliver
* Burn out

@lkundrak @kernellogger This is unfortunately a well-documented issue among maintainers, especially in Linux...

What should instead happen is for him to learn to delegate to others and trust (but verify) their work. Maintainers should understand 50% of their work is mentoring and making themselves replaceable. Anything else is a recipe for burnout, and a rotting subsystem (which none want).

I hope I made sense!

@kernellogger
Yeah, this is a tricky one! The reverse can also be an issue: for instance, I often feel bad for asking (potential) contributors to do more work when I ask them to rework stuff. I usually do so anyway, and don't write a fix myself until they've had a chance to do that (which some do and some don't).

@kernellogger @lkundrak That's... annoying. That tag isn't recognized by most tools, and so it's going to be a pain to query for that with things that index git commits...

@kernellogger @Conan_Kudo @lkundrak I'm not a kernel contributor, but extrapolating the experience from other projects, this one's hard.

If both versions of the fix were reasonably close or, at least, there was *something* from the original in the maintainer's version, two 'Signed-off-by', explaining the differences or stating that's is based on the other could have been fine.

But, in this case, there's nothing from the original in the merged patch, so it wasn't 'co-developed'.

@kernellogger @Conan_Kudo @lkundrak A 'softer-touch approach' could have been, perhaps, trying to led he contributor to write something close to what you're expecting, but that can potentially requite a LOT of time, and we all know many maintainers are overworked, so... it's complicated.

@lkundrak

@kernellogger

Accepting subpar treatment of the community from kernel contributors because it doesn't feel as bad if you stop caring isn't really a productive approach.

Instead of asking the author to care less about attribution, can we ask the maintainer to just give fair attribution where appropriate?

Thinking attribution is only about ego is frankly a bit naive.

@kernellogger as a kernel contributor, I've definitely found it frustrating when i send a patch to a new subsystem and get (often vague) feedback asking me to rework it. Usually im actively trying to learn about other parts of the kernel and being asked to learn this additional subsystem is just more of a burden to progress with the areas i care about.

in this case I'd generally prefer feedback that offers more context about the subsystem, although it's obviously hard to gauge levels here...

haha what about a tool that tells you how many patches someone has in the relevant subsystem and overall to the kernel?

@mupuf @lkundrak @kernellogger it makes perfect sense. Although do consider the scalability - at least in the short run - no maintainer can afford to be very helpful to all contributors. It is unfortunate alas, laws of physics and time do not allow it.

The original suggestion is pretty good IMHO - having a clear and honest indication by the contributor if they are in for the long run or drive-by would help maintainer determine whether to nurture or rewrite.

@xexaxo @lkundrak @kernellogger You are right, Emil. Maintainers cannot be doing the job of university teachers (hence why they should mostly help "capable" contributors), and it is unreasonable to ask maintainers to spend more than 5-10 minutes a day on a new contributor, especially when they have no intention of sticking around.

That being said, people tend to stick around if friction was low and the interaction was nice, not just because they had decided to prior to the first contribution.

@xexaxo @lkundrak @kernellogger At least, that's my personal experience, as a hobbyist or a paid professional.

If a community is hard to work with and I get a lot more frustrated landing my changes than I would be rebasing them, then why would I want to stay there? This is especially true as a contractor, but with money!

This happened to me both inside and outside Linux (hwmon, and MinIO, for example). I may have managed to land my patches if I bent backwards enough, but is it sane to do so?

@xexaxo @lkundrak @kernellogger Disclaimer: While I have been mentoring quite a few students/colleagues over the years. I am only maintaining a handful of projects who see very few users and contributions. This means I definitely need to go the extra mile to retain contributors, and it definitely means I have more time to spare.

That being said, even in such scenarios I could just go faster by doing everything myself, but this would lead to the same outcome: burn-out. Been there / done that :s

@kernellogger that seems like silly over complication. Just say it under the --- line in the patch.

@conor

Of course it's silly and over complication. But at the same it makes something explicit that in an ideal world might be wise for everyone to make explicit, as people will forget to spell it out (and maintainers will forget to ask which of the two it is).

@cas

"what about a tool that tells you how many patches": that's just a few fingertips away (or did I misunderstood what you meant?)

git log --oneline --author='gregkh@linuxfoundation.org' origin/master -- drivers/net/ | wc -l

@kernellogger hah yeah something like that. obviously it's bad to assume, but maybe if maintainers did checks like this when reviewing patches from new contributors it would help with finding the right tone - is this someone with no kernel experience or are they just new to this subsystem?

that being said, it probably comes down to bandwidth as it generally seems to these days