[22:01:36] #startmeeting [22:01:36] robla: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee' [22:01:58] #startmeeting E130: Informal WikiDev '16 agenda bashing [22:01:58] Meeting started Wed Dec 23 22:01:58 2015 UTC and is due to finish in 60 minutes. The chair is robla. Information about MeetBot at http://wiki.debian.org/MeetBot. [22:02:00] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [22:02:00] The meeting name has been set to 'e130__informal_wikidev__16_agenda_bashing' [22:03:09] #topic E130: Informal WikiDev '16 agenda bashing | Wikimedia meetings channel | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [22:03:34] hi folks! [22:04:04] * robla foolishly assumes "folks" are paying attention at all [22:07:41] hi ori! it's *really* busy here today ;-) [22:08:00] heh. I was just looking at https://phabricator.wikimedia.org/T119593 [22:09:08] excellent! Krinkle and I just discussed a lot of the detail work we need to do on the current iteration of the schedule (thanks Krinkle!) [22:10:34] another thing I did out of respect for inertia/habit was to go ahead and have the ArchCom meeting in the past hour. That was basically the Krinkle/RobLa discussion hour, which was very very productive, assuming I follow up [22:12:20] It looks like a good agenda [22:14:25] thanks! [22:15:08] I just posted the minutes from the 1pm PST ArchCom conversation here: https://phabricator.wikimedia.org/E130#1230 [22:15:55] ...and I think I'll just multitask and start making the tweaks now [22:16:05] I have been thinking a lot about the code review one [22:16:34] * robla wants to hear more [22:17:19] I posted https://phabricator.wikimedia.org/T114419#1876179 and then bawolff and I chatted about it on IRC. [22:18:15] I think we should allow self-merging in certain situations. We could bundle that with a requirement for good test coverage. [22:18:51] I think it would improve code quality substantially. But it's a very unpopular opinion, and I am not sure I have the poise and energy to pitch it effectively. [22:19:36] hmm, interesting. that would be a very Facebook-y approach, which wouldn't be all bad [22:20:42] by "Facebook-y", I'm thinking of how Cory Ondrejka characterized the "don't be afraid to break stuff" way of thinking [22:20:45] "certain situations" [22:20:59] If we trust people to review others code, in theory, they should be able to review their own [22:21:09] * robla goes to find the article he's been flogging on that point [22:21:17] robla: I want a chaos monkey to randomly merge things [22:21:39] ooooh, interesting! [22:21:57] my experiences with operations/puppet and mediawiki/core are an interesting study in contrasts [22:22:18] both are complex repos that are mission-critical and have lots of technical debt [22:23:13] i am the first or second most prolific committer to operations/puppet. It was in a horrible state, and I was really motivated to go on a tear and just clean it up. It is way better now than it used to be. [22:23:23] Here's the article I was talking about: [22:23:50] but in a way it's a shame that my energy gets funneled there; I have similar motivations for MediaWiki, but the experience is just so soul-destroying [22:24:02] review cabals! [22:24:32] the big patches with architectural implications can and should be held up for review [22:24:47] From the article, regarding Facebook’s “Move Fast and Break Things” tagline: "It has challenged every new employee to realize it's worth some amount of risk to keep innovating, experimenting and moving forward. And to avoid becoming overly conservative even when a mistake could impact a billion people." [22:25:28] yeah [22:25:30] it encourages responsibility [22:25:49] bawolff's comments were made on #mediawiki so I don't think he'd mind if I reproduced them here [22:25:50] bawolff: ori: One interesting aspect of the code review process, is I'm now a lot less careful about code I push to git. In the svn days I always carefully double-checked everything before comiting because comitting bad code was a really bad thing. Now a days, I still generally test all code before shoving to gerrit, but I'm a lot less careful about it [22:26:09] ori: it's going to sit in code review for a while and get squinted at by people, so this stuff will surface anyway, right? [22:26:09] ori: plus it'll be someone else's fingerprint on the trigger [22:26:10] ori: i don't consciously think that; that would be cynical. but on some level i do. [22:26:11] bawolff: our current process does transfer lots of the risk of development, to people who don't benefit [22:26:13] bawolff: which makes code review a kind of sucky job. Code reviewer is responsible for stuff s/he probably doesn't care about, but is more on the line for it then the person who does care about the code [22:26:27] ori: there's also the great paradox of mandatory code review, which I know you are keenly aware of: the more neglected and ignored a section of the code is, the more difficult it is to get patches for it reviewed [22:26:30] [22:27:37] I read that piece, robla. Yes, it's good. [22:27:55] #info We've been talking about code review a lot for the first half of this meeting [22:27:56] I'm not suggesting we get rid of code review; I'm suggesting we make it optional. Peer pressure and scorn are pretty effective, and I think it's perfectly legitimate to use them to set high standards for code quality. If you self-merge breaking changes or rapidly self-merge controversial changes without giving any time for discussion, you get rebuked. [22:28:33] #link https://phabricator.wikimedia.org/T114419#1876179 [22:30:46] ambling over here .. and reading log .. [22:31:17] nothing too important....just agreeing to do away with code review. carry on! ;-) [22:31:19] i agree on some of the code review drag. [22:32:09] and i've noticed i'm sometimes less careful too because arlo is good at catching problems. [22:32:52] that is in the context of parsoid. [22:32:58] yeah, I think Jeff Atwood's essay on the benefits of code review is very persuasive [22:33:24] #link http://blog.codinghorror.com/code-reviews-just-do-it/ [22:33:40] I guess it's one thing that would be useful if MW had more automated testing (which, I know, is another big tech debt we had) [22:33:54] but anyway, my being less careful is not an argument against code review. :) [22:34:29] I think the way that brion used to do code review was the right way of doing it [22:35:20] his style was basically to look at it closely enough to get the gist, but not try to catch every detail [22:35:56] then TimStarling took over, and Tim takes it very, very seriously [22:36:43] Tim's style of review (as well as csteipp's) is really, really valuable [22:38:11] ...but is doing that depth of review pre-deploy the right technique? genuine question...I don't know the answer. [22:38:46] i can only speak from the parsoid codebase perspective. [22:39:08] in parsoid, we have tons of tests and also rt-testing, and it catches problems almost always .. even when code review missed something. [22:39:42] so, the time code review is useful is in feedback about algorithm, perf, looking at other ways of solving the problem. [22:40:08] but, sometimes it also feels like a drag when everything has ot go through it and we feel backlogged. [22:40:54] arlo and i do most of the reviews .. and sometimes my fingers itch to +2 a patch and then work on followup patches to do additional fixes / cleanup based on testing and feedback. [22:42:17] so, i think for parsoid itself .. i think if we are able to come up with some discipline about what needs review and what can be merged more quickly .. it would help. [22:42:31] so....our assumptions about code review seem to focus on "bringing down the whole site" being the worst thing that can happen [22:42:37] ...but that isn't [22:43:03] ex: https://github.com/wikimedia/testreduce/commits/master .. we pulled it out of parsoid and i am able to do quicker cleanup and fixes than if i had to wait on someone to review every single one of them .. [22:43:04] the worst thing that can happen is a massive privacy disclosure or security hole [22:43:57] * subbu is done [22:44:57] And the most common being respecting revision deleting and hiding etc [22:45:09] Which, usually in an extension, crops up "regularly" [22:46:10] so....I think this has been a good preview of what that session should be at WikiDev [22:47:02] * robla totally agrees with Reedy btw, just looking at the time and wanting to talk about WikiDev '16 agenda [22:51:17] * robla gloats over successfully slaying what meager momentum this meeting had ;-) [22:52:03] I think Tim's style was at least partially mandated by the fact that it fell on him to deal with breakage [22:53:05] re: ex: https://github.com/wikimedia/testreduce/commits/master .. we pulled it out of parsoid and i am able to do quicker cleanup and fixes than if i had to wait on someone to review every single one of them .. [22:53:25] so...I would like to move on from code review at this point [22:53:28] I think most teams have resorted to something like that to work around the code review gridlock [22:53:29] and talk about https://phabricator.wikimedia.org/E130#1230 [22:53:35] OK! [22:54:17] ori, to be clear, in that case, we knew we needed a new repository. the decision to put it on github was motivated by the code review gridlock. [22:54:21] instead of on gerrit. [22:54:24] Krinkle had some very good suggestions about what was/is currently confusing about the summit schedule [22:54:27] really done :) [22:55:02] are there any others? is Krinkle the only one I'm going to get code review on the schedule from? ;-) [22:55:11] > T115762: Shadow namespaces at the 2016 Wikimedia Developer Summit: for the reasons exposed at T119030#1851922, if @Legoktm wants to push for this, we will support him. [22:55:47] When I emailed wikitech-l, I don't think anyone responded, so I didn't think there was much interested except from Krenair who I was going to just chat with on the side [22:56:04] #info legoktm pointed out T115762 [22:56:16] #link https://phabricator.wikimedia.org/T115762 [22:56:25] legoktm, i thought that had a lot of interest ... based on looking at the community wishlist survey? [22:56:44] subbu: from users, not sure about developers ;) [22:57:10] ah, i see. [22:58:21] robla, I haven't been able to keep track of summit schedules, sessions and wikitech-l threads .. so, i have no useful suggestions about the session. [22:59:04] legoktm: pretend this is the almost final schedule https://phabricator.wikimedia.org/T119593#1900298 ...where would you suggest we put T115762? [22:59:56] * robla plans to go longer than normal since he doesn't think there's anything scheduled after this in #wikimedia-office [23:00:44] subbu: understood about schedule stuff. we're in for quite the retrospective on the planning for this year ;-) [23:00:56] robla, why is T114072:
tags for MediaWiki sections in 2 places? [23:01:50] subbu: yup, good point. I'll make sure to fix that one [23:02:52] subbu: which clone would you suggest eliminating? [23:04:53] the tuesday one? [23:05:30] my initial instinct is have the
tags one at 3:40pm on Monday, then put the Language one at 11:30am on Tuesday, but as I was typing that, you responded the other way, I think :-) [23:05:45] i think the 2 sessions on monday seem different enough and not everyone will be interested in both. [23:06:17] i said elimiante the tuesday one and keep the monday one. [23:06:29] ahhhh, ok [23:06:38] yup, we agree then \o/ [23:06:56] robla: not really sure, I also want to go to most of the other sessions :) Compared to the other sessions there's less developer interest, so maybe it could be an unconference thing? [23:08:26] my not-so-secret motive is to make the Robertson 1 sessions (the 200 person room) so compelling that no one wants to go to the other sessions :-) [23:09:59] the IETF has a very similar problem in scheduling their meetings, only way more complicated [23:10:38] the end result of any of the meetings is not to officially decide anything, but to basically have it be all-but-decided [23:11:29] but, at that size (200), will it really have sufficient discussion in a 90 min slot? [23:11:31] i.e. if you miss the session, and then you try to use the excuse "I couldn't be at that session", that doesn't give you the ability to reset the whole conversation [23:11:54] ah .. reg. resetting conversation. [23:11:55] subbu: IETF meetings work like that all of the time [23:13:13] Are we going to actually have 200 people? [23:13:32] 175 is the registered # [23:13:32] the fire department says that's our maximum ;-) [23:14:28] I'm guessing that really, it'll "only" be 20 people who insist on microphone time in any particular meeting [23:14:56] ...and then many more interested observers [23:15:30] and people who speak through etherpad :P [23:15:31] ...and then many other people checking their emails and occupying seats because they are too lazy to move :-/ [23:16:49] legoktm: amen [23:18:02] alright...that seems like a good place to put the "endmeeting" mark, unless anyone has anything they want to say for the record [23:18:19] quickly skimming through https://www.mediawiki.org/wiki/MediaWiki_Developer_Summit_2015#Schedule, I don't think we have any workshop-type things this time around? [23:19:27] #action robla move the
tags one at 3:40pm on Monday, then put the Language one at 11:30am on Tuesday [23:20:12] legoktm: yeah, that's right, for a number of reasons [23:20:56] the most practical reason right now is that I don't think there are any workshops in the session proposals list (are there?) [23:21:52] yeah, I don't think I saw any [23:22:31] #action robla: follow up on T115762 Shadow namespaces scheduling [23:23:04] anything else we should get in the record for this meeting? [23:23:48] * legoktm doesn't have anything :) [23:23:58] going once.... [23:24:14] twice... [23:24:28] #endmeeting [23:24:29] Meeting ended Wed Dec 23 23:24:28 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [23:24:29] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-12-23-22.01.html [23:24:29] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-12-23-22.01.txt [23:24:29] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-12-23-22.01.wiki [23:24:30] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-12-23-22.01.log.html [23:24:40] o/ [23:25:26] I suppose one thing I should have gotten in the record: thank you! this was a really productive conversation [23:26:07] I'll still be available in #wikimedia-tech to talk more about this. we should move the remainder of any discussion about WikiDev '16 over there