21:00:22 #startmeeting RFC meeting (E316) 21:00:22 Meeting started Wed Oct 12 21:00:22 2016 UTC and is due to finish in 60 minutes. The chair is robla. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:22 The meeting name has been set to 'rfc_meeting__e316_' 21:00:36 #topic RFC: CREDITS file (T139300) | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) |​ Logs: https://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ 21:00:36 T139300: Create formal process for CREDITS files - https://phabricator.wikimedia.org/T139300 21:00:49 hi folks 21:03:01 we had a conversation that jdlrobson started about the CREDITS file that was going strong a while back on wikitech-l, but tapered off 21:04:25 he asked about the signifcance of this: "We would like to recognize the following persons for their contribution to MediaWiki." 21:05:08 is there any reason we shouldn't go through and get everyone that contributed a few lines of code? 21:05:34 nope. {{done}} 21:06:04 settled! :-) 21:06:06 git log --format='%aN <%aE>' | sort -f | uniq 21:06:28 Is there any reason we distinguish between "Patch contributor" and "Developer" here > https://en.wikipedia.org/wiki/Special:Version/Credits 21:06:28 * robla tries that just to see what emerges 21:07:19 looks like you may need to add LC_ALL=C for the sort to work 21:07:21 Note according to that page yuvi panda is not a developer which seems a strange statement :) 21:12:05 I think the difference between developer and contributor is pretty arbitrary at this point 21:12:20 it may have once meant something, but it feels stale 21:12:39 https://phabricator.wikimedia.org/diffusion/MWVA/browse/master/.mailmap 21:12:41 The "old timers" should weigh in on that though I think 21:13:08 I think it means I paid off the right person back when access was through SVN :> 21:13:54 legoktm moved my entry from one list to the other. It made me feel good but otherwise did not change my life 21:14:11 yeah, the developer vs contributor distinction was clearly an SVN commit access versus "ask someone to patch for you" 21:15:10 back in ye olden days of SVN and post-commit review. Post-commit review made being a "developer" a much bigger deal 21:15:52 ah. so developers had "karma" to commit to the trunk? 21:16:11 bd808: yeah, essentially 21:16:56 committing to trunk wasn't as big of a deal because trunk only got deployed 2-3 times a year 21:18:16 hello 21:18:20 #info 14:06:05 git log --format='%aN <%aE>' | sort -f | uniq 21:18:31 legoktm: hi! 21:18:41 so the hard part of implementing this change will be making the mailmap file. There are 643 lines right now but many are obvious dupes 21:18:47 Hello Legoktm (and All)! 21:19:46 oh hi netsplit. we missed you 21:20:10 I could see making a distinction for people with +2 ("Developers") and then other contributors as we want to recognize those people more 21:20:59 bd808: what would the mailmap line look like for Bryan Davis ? 21:21:40 robla: probably something like " " 21:22:12 I think that's the order to say that is preferred 21:23:37 apparently James_F has already started a .mailmap for us that just needs some updates 21:24:06 there's a bikeshedding conversation we could go through on this 21:24:14 red! 21:24:15 I'd be in favor of just having one giant list in CREDITS 21:24:16 blue! 21:24:23 legoktm: +1 21:24:27 legoktm: what would be the criteria? Right now we have no criteria which makes that hard. If someone asks to be moved to "Developers" how do we assess that? 21:25:11 But I'd like to retain the hardcoded list at the top of Special:Version for people who have made long term/lasting contributions to MW 21:25:18 there's a bikeshedding conversation we could go through on this. seems sensible to have one line per contributor rather than unique email 21:26:20 jdlrobson: well if there are two lists, I think the only reasonable distinction is either LOC or whether they have +2 or not. But the latter devalues SVN commiters (or we assume everyone with SVN access == +2?) 21:26:51 Which is why I'm in favor of just one list in CREDITS 21:27:12 I think it simplifies ** a lot ** especially if it's autogenerated 21:27:21 agreed 21:27:23 i see a lot of inconsistencies between https://github.com/wikimedia/mediawiki/graphs/contributors and the developers list 21:27:46 jdlrobson: well, github's list is probably more wrong because it requires you to have a github account, and associate your commit email with github 21:28:28 possibly.. but for example I see Florian in patch contributors but commit wise he's on par with Matt Flaschen 21:29:11 Probably just because no one has thought to move him :) 21:29:18 * Reedy goes to fix that 21:29:26 we're counting just core, right? 21:29:32 jdlrobson: I'm confused, I've said twice now that we should just merge the two lists into one. Do you want to keep them separate? 21:30:17 to be clear i think one list makes sense 21:30:47 Krenair: yeah, what we're talking about now really only covers core, but you're right, there's also another big complicated conv about libraries and extensions 21:30:49 Okay, does anyone disagree with having one list in CREDITS? 21:31:46 Right now myself, jdlrobson, and bd808 have expressed support for one list 21:31:58 Well it depends how that list is made. If it's hand curated we still have some of the same problems... but definitely one list is better than 2 21:32:09 legoktm: I don't think there is anyone here who does. add me to the "support" list 21:32:55 Can I #agree that? Or is that too bold? 21:33:03 we didn't really have an ArchCom quorum for the earlier planning meeting, so we probably don't have the usual suspects here, either 21:33:24 I can poke Tim who's sitting next to me ;) 21:33:37 please do! :-) 21:34:20 I'm inclined to say #agree on this, even if it's just the handful of us active in this conversation 21:34:36 it's fine with me 21:34:47 jdlrobson: How to structure this here to scale, depending on WMF and Wikidata's plans? ... "legoktm: what would be the criteria? Right now we have no criteria which makes that hard. If someone asks to be moved to "Developers" how do we assess that?" ? 21:34:55 jdlrobson: I think the list should be generated via git. As to when to do that, monthly? 21:35:12 bd808: +1 21:35:23 I assume we could do that as a deploy script? 21:35:28 bd808: sounds good to me. at minimum, right before a stable release 21:35:30 (or per release) 21:35:47 As a pre-branching (for release branching) task makes sense 21:35:47 #agree The "Developers" and "Patch contributors" sections in the CREDITS file should be merged into one list 21:35:49 oh! at release cut would be easy I think 21:36:05 thanks legoktm 21:36:13 No point doing it per WMF branch etc 21:36:13 yeh thanks legoktm bd808 21:36:28 we could just get the `git log --format='%aN <%aE>' | LC_ALL='C' sort -f | uniq` bit added to whatever magic script is used by releng 21:36:34 Scott_WUaS: was that a question? 21:37:15 bd808: that seems like a really good approach 21:37:37 jdlrobson: yes, it was a question ... 21:38:31 And similarly what does WMF do now, in lieu of not having such criteria ... to build on? 21:38:43 Scott_WUaS: we just agreed to merge the two lists. 21:38:43 Or Wikidata? 21:38:55 Thx 21:39:01 Scott_WUaS: I think it depends on the scope of the CREDITS file. For the mediawiki/core repo, that seems reasonably clearly scoped to just that. but yeah, in terms of "developers on the cluster", it's harder 21:40:06 https://en.wikipedia.org/wiki/Special:Version links to https://en.wikipedia.org/wiki/Special:Version/Credits 21:40:15 robla: thx ... (Curious how other software organizations do this with teams or "developers on the cluster" ... a Google, an IBM et al .. thx) 21:40:34 and of course: https://translatewiki.net/wiki/Translating:MediaWiki/Credits 21:41:40 robla: language by language makes WMF credits for "developers on the cluster" much more complicated, I imagine :) 21:41:55 it does 21:42:43 (robla: what are best practices, Scott_WUaS wonders) 21:42:53 btw: we're going to have end this meeting 5 min early to make sure we get a log before the Freenode maintenance happens 21:43:26 So I think the part that still needs to be discussed is the implementation and frequency of updating that list? 21:44:10 We've got a general suggestion of generating via git-log and adding that as a branch cut step 21:44:30 s/branch/release branch/ 21:44:56 legoktm: per-tarball release branch (2 times a year) seems like a reasonable cadence to me 21:45:07 any objection to that frequency? 21:45:29 sounds good to me 21:45:55 #agree update 2 times a year; each time a release branch gets cut 21:45:55 and that person would also be responsible for updating the .mailmap or? 21:46:42 mailmap tuning would be easiest based off that diff 21:46:44 I think the implementation is somethign that should probably should have some further discussion 21:47:06 but yeah it seems like a fine grained detail 21:47:11 we might be able to first use a simple mailmap on the mediawiki/core branch, and then iterate from there 21:47:24 s/core branch/core repo/ 21:47:56 seems like we should strive to move toward a more suitable list for Special:Version off of our big wikis 21:48:02 we have a 333 line .mailmap already but it seems to be missing some obvious dups 21:48:34 I think we all agree that the status quo is lacking 21:49:01 ...so the bar isn't very high for an improvement. someone could submit a patch that is a manual update of the CREDITS file 21:50:02 it seems maybe this is the order of operations: 21:50:15 The .mailmap looks very inconsistent 21:50:29 1. update the RFC for what we want the minimum-viable product for an update script 21:50:59 2. update the CREDITS file manually from a very early version of the script 21:51:30 3. discuss the update in Gerrit/Phab/wherever, manually updating for the mistakes that were made in the first run 21:52:03 4. do manual updates until someone finds the time to automate it 21:52:20 does that seem like a good way forward? 21:54:24 jdlrobson: I guess I'll ask you as the author: does that seem like a sensible path forward (possibly handing off the RFC to someone else to follow through on) 21:55:15 that sounds good to me 21:55:39 I guess my only remaining question is what happens to the existing CREDITS file bundled in core 21:55:58 if that stays in the same repo we should be clear that people shouldnt add their names there and that its automatically generated 21:56:06 if it's not in the repo, then we dont need to worry 21:56:08 sounds good Rob! 21:56:24 I think it gets replaced by the first person bold enough to replace it 21:56:54 as far as the automatic generation, we'll have to make a point of putting in warnings 21:57:22 ...and probably manually eyeball it each run to ensure we didn't accidentally remove someone who was manually added 21:57:33 (robla: this may be a bag of worms, but what relationship is their between crediting and compensation - and are these CREDITS for both volunteers as well as staff? 21:58:03 *there 21:58:15 anyway...we're about to lose access to Freenode, I think, so I'm going to end the meeting in 30 seconds 21:58:29 we can continue the conversation in #wikimedia-tech 21:58:33 Thank you, All! 21:59:04 next week, we may be talking about T145472 21:59:05 T145472: Surveying Cookie Use - https://phabricator.wikimedia.org/T145472 21:59:17 #endmeeting