wikitech-l discussion: "Crediting the work of our community members"

Research

jQuery

• AUTHORS.txt file, containing all commit authors (link). Auto-generated with build script (typically once per release cycle).
• "Copyright jQuery Foundation and other contributors,"
• "For exact contribution history, see the revision history available at https://github.com/jquery/jquery"

VisualEditor

• AUTHORS.txt file, containing all commit authors (link). Manually updated from time to time. Grouped by "Principal Authors" and "Patch Contributors". Curated by project maintainers (CR+2).
• "Copyright (c) 2011-2016 VisualEditor Team and others"
• "This software consists of voluntary contributions made by many individuals (AUTHORS.txt) For exact contribution history, see the revision history and logs, available at https://gerrit.wikimedia.org"

MediaWiki

• CREDITS file, containing some (?) commit authors (link). Manually updated, grouped by "Developers" and "Patch Contributors", curated by project maintainers (CR+2).
• SpecialVersion::getCopyright hard-coded array, containing principal authors (link). Manually updated and curated by project maintainers (CR+2).
• "MediaWiki contributors, including those listed in the CREDITS file, hold the copyright to this work."

Proposal

Basically the "Abandon CREDITS files" proposal mentioned in the opening post.

• Make CREDITS an inclusive list of all commit authors. Can be generated by a grunt task or maintenance script that uses commit log and mailmap via Git command-line (similar to jQuery and VisualEditor).
• And, on top of that, one of these two options:
  • Remove grouping from CREDITS file and keep hardcoded list in SpecialVersion
  • Or; Remove hardcoded list in SpecialVersion and read it from a new section "Principle authors" in the CREDITS file. The script can be taught to keep that list unchanged and exclude its entries from the contributors list.

Is there a potential, perhaps corner case issue, that the commit individual is not actually the person contributing to the code (e.g. making commits for someone else)? If so, should we also allow a way to manually curate the list if necessary?

I think having a document policy as noted in the opening post is also a great idea.

In T139300#2500359, @ZhouZ wrote:

Is there a potential, perhaps corner case issue, that the commit individual is not actually the person contributing to the code (e.g. making commits for someone else)? If so, should we also allow a way to manually curate the list if necessary?

I think having a document policy as noted in the opening post is also a great idea.

In principle git suppports having both a commiter and an author field. The two fields can be separate. In practice, I'm sure it can happen on occasion that someone doesn't set the author field correctly.

In T139300#2500359, @ZhouZ wrote:
Is there a potential, perhaps corner case issue, that the commit individual is not actually the person contributing to the code (e.g. making commits for someone else)? If so, should we also allow a way to manually curate the list if necessary?

I think having a document policy as noted in the opening post is also a great idea.
In principle git suppports having both a commiter and an author field. The two fields can be separate. In practice, I'm sure it can happen on occasion that someone doesn't set the author field correctly.

Thanks. Should we then allow the manual curation of the list if necessary?

We briefly discussed this in the last couple of planning meetings (E250, E258). I'm taking on TechCom-RFC shepherding responsibilities for this.

@Jdlrobson: ArchCom discussed this as a possible topic for next week's IRC meeting (E316 2016-10-12, Wednesday 2pm PDT). Do you think that's a good idea? Relatedly, are you available at that time?

Change 315607 had a related patch set uploaded (by BryanDavis):
Convert CREDITS to list of all known git contributors

https://gerrit.wikimedia.org/r/315607

Change 315621 had a related patch set uploaded (by BryanDavis):
Convert CREDITS to single list of contributors

https://gerrit.wikimedia.org/r/315621

Thanks for working on this!
Once merged and dust has settled, https://gerrit.wikimedia.org/r/#/c/211034/ should get abandoned I guess?

In T139300#2712491, @Aklapper wrote:

Thanks for working on this!
Once merged and dust has settled, https://gerrit.wikimedia.org/r/#/c/211034/ should get abandoned I guess?

I just merged it just to make the question moot :-)

Change 315621 merged by jenkins-bot:
Convert CREDITS to single list of contributors

https://gerrit.wikimedia.org/r/315621

Change 315607 merged by jenkins-bot:
Convert CREDITS to list of all known git contributors

https://gerrit.wikimedia.org/r/315607

Removing 1.28 tag because it doesn't block a release.

Okay, but I'd still like to see these patches included in 1.28.

That's fine, go ahead and do the backports. I'm just saying it's not worth blocking the release if you don't get to it :D

Change 320927 had a related patch set uploaded (by Legoktm):
Convert CREDITS to single list of contributors

https://gerrit.wikimedia.org/r/320927

Change 320927 merged by jenkins-bot:
Convert CREDITS to single list of contributors

https://gerrit.wikimedia.org/r/320927

Change 320933 had a related patch set uploaded (by Legoktm):
Convert CREDITS to list of all known git contributors

https://gerrit.wikimedia.org/r/320933

Change 320933 merged by jenkins-bot:
Convert CREDITS to list of all known git contributors

https://gerrit.wikimedia.org/r/320933

Yes! This is great to see and thank you for all involved for shepherding this along and making it a reality.
https://en.m.wikipedia.beta.wmflabs.org/wiki/Special:Version/Credits

I think this task can be resolved now?

In T139300#2791807, @Jdlrobson wrote:

I think this task can be resolved now?

One part that is left to work on is integrating the new maintenance/updateCredits.php script into the release branch cutting process as something that is either automatic or a well documented manual step. It seems pretty likely that we will need .mailmap additions when this is done as well to de-duplicate contributors that have used a variety of local git configs when uploading patches.

In T139300#2792588, @bd808 wrote:

In T139300#2791807, @Jdlrobson wrote:

I think this task can be resolved now?

One part that is left to work on is integrating the new maintenance/updateCredits.php script into the release branch cutting process as something that is either automatic or a well documented manual step. It seems pretty likely that we will need .mailmap additions when this is done as well to de-duplicate contributors that have used a variety of local git configs when uploading patches.

Considering the release process is mostly manual and the docs for releasing are a mess.... ;-)

In T139300#2792650, @demon wrote:

Considering the release process is mostly manual and the docs for releasing are a mess.... ;-)

So automation is off the table? Where are the messy docs that I can at least add some rambling paragraphs to? I found https://www.mediawiki.org/wiki/Release_checklist which looks to have at least been recently touched.

In T139300#2796034, @bd808 wrote:

In T139300#2792650, @demon wrote:

Considering the release process is mostly manual and the docs for releasing are a mess.... ;-)

So automation is off the table? Where are the messy docs that I can at least add some rambling paragraphs to? I found https://www.mediawiki.org/wiki/Release_checklist which looks to have at least been recently touched.

Not off the table, but hasn't happened (I never have the cycles). Feel free to add it to that page, it's the closest thing to docs we really have...

Added to release process checklist: https://www.mediawiki.org/w/index.php?title=Release_checklist&diff=2285822&oldid=2269190