Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My conclusion:

* It wouldn't have hurt to give Ariel more credit with a `Co-Authored-By` instead of `Reported-By`, especially considering that the 'report' came with a working code fix. If this form of credit is outside the typical Linux commit authoring norms, then maybe this is a good motivation to adjust them.

* Ariel should have brought up the complaint about the Reported-By tag at the time instead of letting his frustration and disappointment fester for a year then writing a blog post about it.

* The "(paraphrased)" maintainer response to asking for more credit feels off, and the formatting of the blog post is badly misleading. I'd much prefer a direct quote than a paraphrasing for something like this, where it's important to have raw data for third parties (like everyone in this thread) to come to a valid judgement on this aspect.

* I can't tell if this was communicated in private or if the response is contained in one of the links mentioned in this thread. In general the whole timeline is rather difficult to follow which doesn't help.

Between this and the recent rust drama, I think we're running face first into the biggest issue of text-only communication mediums: it's really hard to communicate intent and feelings through text. You can dismiss that as silly human foibles, but the human shit actually matters. In person communication has such a higher bandwidth it's insane, and if we're going to continue pretending that we can replace it entirely with text, we will have to commit to a much higher level of transparency and candor than we'd feel comfortable with in person, else it will be harder than necessary to maintain community over the long run.



I'm pretty sure if the OP would have just sent the maintainer an email that he thought he deserved more credit would have been all it took to get it fixed. He was also given an opportunity to get more credit for another issue and that would have cemented his commitment to becoming a regular contributor.

Both sides could have done better, but this level of attack is unwarranted for what happened and if Michael Ellerman is capable of seeing that they could have handled the situation better then I'd hope the OP has the insight that they too could have handled this better, for instance by communicating with the maintainer directly.

Your point about communications is well noted, I think a part of it stems from a combination of workload on the part of the maintainer(s) and unfamiliarity with the various processes and attitudes as well as the absence of even clearer rules on how kernel maintainers should deal with various levels of contributions.


> just sent the maintainer an email that he thought he deserved more credit would have been all it took to get it fixed

Agreed completely.

> workload on the part of the maintainer(s) ... unfamiliarity with the various processes ... absence of even clearer rules

Yes these all contribute to the problem. The 'culture' of an open source project is basically opaque to a new contributor, no matter how "open" project's comms are a new contributor can't read them all. That's why it's unreasonable to expect them to be able to completely understand the rules, processes, and workloads that affect everyone involved in the environment where they are just making a new contribution.

Which is why embracing the messy humanity and going all in on radical candor is the best solution. The other option is giving every new contributor a 10M word reading list just to catch up on the context, which is so impractical it's hardly worth mentioning.


One issue may be the perceived intentions of the OP in the original conversation, they did mention credit but they also switched to their corporate email right in the middle (probably because they used company resources or to give the request more weight) which could have been easily interpreted as 'Cisco wants this stuff fixed pronto' and that may have been a misinterpretation about the goals of the OP, which - given the time span involved between the original fix and the blog post - may well have shifted over time.

But Michael Ellerman's graceful apology puts to rest any kind of perceived bad intentions and the way the pitchforks have been brought out here to skewer a maintainer that simply made a - small - mistake in the heat of the moment is reminiscent of the the treatment of some other maintainers who chose to step down instead of to continue to be dumped on for just getting their job done. The OP made mistakes and did some questionable stuff, Michael Ellerman made a mistake but to me seems to have maintained the high ground from a moral perspective in spite of all of the vitriol here, including that from the OP.

If anything that thread is a model of restraint.


Oh I found the thread with Michael's response, I hadn't seen that. I think your assessment is reasonable.

https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/m...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: