LWN: Comments on "Managing expectations with a contributions and credit policy"

Managing expectations with a contributions and credit policy

Hi-Angel — Wed, 03 Jul 2024 22:39:58 +0000

It's cool to be able to have such attitude. I can only have it when I'm being paid for contributions (which is almost never) — in that case I don't care if I won't be mentioned at all, I just like that my commits improve something Linuxish. But when I spend my personal time on the commit, I usually want to have at least something off of my contributions.

Another notorious project where maintainer always does that kind of stuff is the accessibility plugin for programmers called "emacspeak". The maintainer always just takes the credit for the commits and outright ignores any kind of complaints, so after having a few patches to the project I stopped contributing there. But if I was paid by someone for the commits, I think would let it pass.

Managing expectations with a contributions and credit policy

wiktor — Tue, 28 May 2024 12:31:18 +0000

Agreed, that in most cases the problem just doesn't appear if you've got a good team and if you've got a bad team then patch authorship is the smallest of your problems.

As a maintainer I sometimes have to fix the PR of a contributor that disappeared and the PR is in conflict. I usually leave the author but append myself as `Co-authored-by` if the conflict resolution is not trivial or needs further adjustments or code changes (e.g. adding test cases).

Managing expectations with a contributions and credit policy

jezuch — Tue, 21 May 2024 04:59:58 +0000

You're right, it's trivial to abuse it and does not mix well with people with inflated egos, or who like to game the system. Maybe I didn't think about it because I work with decent people ;) I'm not sure we have anything much better, though.

FWIW, GitHub will display all authors (and also the committer) on a list of commits in a PR, as icons next to each commit. When you open a particular commit, the primary author is obviously emphasized, though.

Managing expectations with a contributions and credit policy

vaurora — Fri, 17 May 2024 06:42:12 +0000

Oops, I should be clear: entire new hacks in xscreensaver are credited with the author's name in the source file, but afaict no other named credit is given.

Managing expectations with a contributions and credit policy

vaurora — Thu, 16 May 2024 11:34:56 +0000

I wrote a long discussion of the subtleties of the "Co-authored-by:" tag but ended up cutting it.

Short version: "Co-authored-by:" is an important and critical tool for giving secondary credit. Most people use it to give credit to someone who wrote a small part of a larger contribution that can't be contributed separately and otherwise would not have gotten formal credit at all. But I've seen people who make a habit of slightly editing almost every PR, making themselves the primary author of the commit, and making it look less bad by booting the primary author to "Co-authored-by:". This is slightly better than maintainers who do this and demote the primary author to "Reported-by:" or "Signed-off-by:", but if it's being used as a plausibly deniable way to usurp credit, it's a net loss IMO.

The difference between primary author and co-author is important: most software, including git itself, chooses to display only the primary author. For example, some IDEs show the git primary author of each line; the co-author only shows up if you look at the entire log message. So a contributor spends 99% of their time seeing the primary author repeated hundreds of times and 1% seeing the co-author scroll by once. I know GitHub has some support for "Co-authored-by:" but it seems a little fiddly.

Another important point is that it's mostly only maintainers who have the power to do this: the contribution shows up with the correct primary author, the maintainer makes some easy changes, decides they deserve primary credit, changes the authorship, and check it in. A contributor can't do the same thing to a maintainer. So misuse of "Co-authored-by:" tends to be solely by maintainers or other gatekeepers, just like other forms of taking credit unfairly.

People will still argue about whether "Co-authored-by:" is significantly different than primary author, but watch what people do: most people prefer and will fight for credit as primary author.

Managing expectations with a contributions and credit policy

jezuch — Thu, 16 May 2024 07:11:14 +0000

There is this semi-standard "tag" in git (though there is no formal concept of a tag in git) which is "Co-Authored-By:". At least GitHub can recognize it and we use it pretty often at $DAYJOB to give credit where appropriate. I'm not sure it gives the coveted "green box" but it should :)

Managing expectations with a contributions and credit policy

NYKevin — Thu, 16 May 2024 04:59:58 +0000

I must admit that I find the entire concept of "accept somebody else's patches, but don't give credit for them" rather baffling.

Maybe it's because I work for a ruthlessly cold-blooded faceless corporation, where the company owns everything and managers want to know who did what.

Managing expectations with a contributions and credit policy

vaurora — Wed, 15 May 2024 18:41:46 +0000

It's funny, I did not even realize I had neither received nor expected credit for that tiny xscreensaver bug fix until I wrote the third draft of this article. As another commenter said, it was clear that outside contributions were neither solicited nor credited, so my expectations for receiving credit were accurately set to "none." I just was excited that I had found and fixed a real bug in software that I and my friends used all the time. (Because I'm like that, I also liked that I had found it while doing something the creator despised.)

Managing expectations with a contributions and credit policy

vaurora — Wed, 15 May 2024 18:33:42 +0000

Style guides are important and useful! This project is trying to focus more on the process of handling contributions than the style of the initial submission. But it is useful for the same reason as a style guide: you set expectations once and don't have to spend time doing it again.

Managing expectations with a contributions and credit policy

Wol — Mon, 13 May 2024 20:22:28 +0000

I guess this sort-of complies with a "contributions and credits policy" - guidelines of how to behave on a wiki ...

https://raid.wiki.kernel.org/index.php/Editing_guidelines

And I have reverted the odd change or rewritten wholesale stuff that didn't comply!

Cheers,
Wol

Managing expectations with a contributions and credit policy

dkg — Mon, 13 May 2024 19:47:58 +0000

Thanks for this article! This kind of meta-programming topic (how do we formally organize the social work that is required to build a functional, maintainable ecosystem) isn't as widely discussed as it should be here on LWN. I'd love to see more articles like this, with pointers to good examples.

I hope folks involved with any project that has such a contributions and credit policy (even a light-touch one, as long as it is thoughtful) will send a pull request to get it added to the list of known policies) so that the community can have a wider view of existing formalized practices.

Managing expectations with a contributions and credit policy

jwarnica — Mon, 13 May 2024 18:39:30 +0000

JWZ mostly only sells beer now, though came to fame dealing with patch submissions being rejected for, er... reasons.

On the other hand, he is arguably personally responsible for Mozilla being open sourced, so we can cut him some slack. And on the point of his very personal screensaver project, in particular, it takes little effort to realize it is a very personal project; there isn't even a public git repo, desires to make it "better" by modernizing it are met with contempt.

It wasn't quite the authors point, but sometimes very valuable things, things very valuable to the community, are built for very personal reasons, which could be not ever dealing with idiots while gifting the world. xsreensaver has never pretended to be anything but what it is, let alone a nurturing community.

I also don't think it was the authors point that they were personally expecting anything different.

Managing expectations with a contributions and credit policy

NightMonkey — Mon, 13 May 2024 17:26:59 +0000

One of my early open-source contributions was guided by a contributions policy of sorts. The xjack screensaver prints "All work and no play makes Jack a dull boy" over and over, with a variety of mistakes and typos, inspired by a scene in The Shining. A comment in the source code tells would-be contributors not to bother sending in a patch to change the words it prints. However, while I was doing exactly that, by changing it to print "All work and no play makes Val a dull girl", I found a bug in the code that generated typos. I sent in a patch to fix that bug, which was merged (without credit).

That kind of thing can sting, and is very discouraging in my personal experience. I hope the project makes amends, if this is was the case. Do you have the commits of the code you wrote? I'm glad that you didn't let it stop you from participating in Open Source projects.