[22:00:33] * robla starts getting ready for E135 [22:01:15] https://phabricator.wikimedia.org/E135 [22:02:50] #startmeeting "Wikimedia ArchCom governance: https://phabricator.wikimedia.org/E135 | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/" [22:02:51] Meeting started Wed Jan 20 22:02:50 2016 UTC and is due to finish in 60 minutes. The chair is robla. Information about MeetBot at http://wiki.debian.org/MeetBot. [22:02:51] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [22:02:51] The meeting name has been set to '_wikimedia_archcom_governance__https___phabricator_wikimedia_org_e135___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:10] hi folks! [22:03:50] #topic Goal: Review T123606: WIP RFC: Improving and scaling our technical decision making process [22:04:38] hi [22:04:55] Hi as well [22:05:01] o/ [22:05:10] recently, we have been discussing improvements to our decision making process & governance model [22:05:14] hi [22:05:20] we've been talking at WikiDev '16 and in hallway track about governance models and what to emulate [22:05:50] I think there is a general feeling that the RFC process has been very useful for broadening the involvement in technical decision making [22:05:56] Gabriel did a great job on a first draft for T123606 [22:06:04] * robla gets the link [22:06:15] but, there are also things that we can improve, possibly by stealing ideas from other communities [22:06:31] #link https://www.mediawiki.org/wiki/Requests_for_comment/Governance [22:06:44] https://phabricator.wikimedia.org/E135 [22:07:10] I wrote up some of the issues I see on the RFC, but am curious to hear your thoughts on where things could be improved [22:07:36] (and by wrote up, I mean really just sketched) [22:07:50] * robla sheepishly admits not having a chance to followup on edits to Gabriels draft [22:08:45] we also looked at what other communities have been doing [22:08:53] Here are three main questions from Gabriel: [22:08:54] How does ArchCom membership work? How should it work? What is the current roles and responsibilities of ArchCom membership? Do we want permanent "areas" like IETF? Do we also/instead want temporary WGs? [22:09:10] Is the RFC meeting happening? [22:09:22] dapatrick: yup [22:09:29] we're in it now [22:09:42] Scott_WUaS: those are all excellent questions about possible solutions [22:09:50] Hmm. Is there a different hangout link? [22:09:54] I'm in mediawiki-rfc [22:09:57] I wonder is this for intra-WMF process or wider? Because mediawiki has wide usage outside WMF, for example - would we want somehow include these people into the process? [22:10:00] agreed, Gabriel [22:10:10] I'd like to solicit some input on the problems first [22:10:32] dapatrick: oh....this is IRC only. sorry, there must have been a hangout accidentally put in cal [22:10:34] before we move on to exploring the solution space [22:10:44] Ah, I see. [22:11:39] SMalyshev: great question [22:12:05] robla, now would be a good time to mention the people (including me) discussing possibility of MediaWiki Foundation. [22:12:11] the archcom membership is essentially self-selected: an invitation to join the committee is put forward as a resolution of the existing committee [22:12:12] SMalyshev: it is targeted at our decision making as an engineering community [22:12:20] That is still in very early stages, so shouldn't block this discussion. Just wanted to mention it. [22:12:28] the initial members were chosen essentially by seniority [22:12:43] That MediaWiki Foundation discussion (re-)started at the Dev Summit. [22:12:49] SMalyshev: which includes third party users, but has a heavy WMF presence [22:13:00] gwicke: aha, ok [22:13:39] we changed the name of the developer summit over time. 2015 was the "MediaWiki Developer Summit", and this year, it was "Wikimedia Developer Summit". I think that was a good change [22:13:41] do you feel that the four issues mentioned on the RFC make sense? [22:13:47] matt_flaschen: what do you think the relationship between MWF and ArchCom should be? [22:14:12] matt_flaschen: (and please, find a different name - the mediaWiki vs Wikimedia confusion is bad enough as it is) [22:14:12] This is just my personal opinion, but ArchCom could be a committee of MWF. [22:14:22] DanielK_WMDE, yes, I actually suggested MediaWiki Association. [22:14:33] But that is still undecided. [22:14:41] gwicke: I do [22:14:43] Gabriel, are these they - [22:14:44] However, we are also seeing issues with the current process: Lack of clarity on the overall technical direction of MediaWiki and the Wikimedia platform. Difficulty of scaling the decision making process. Stakeholder involvement & legitimacy. Clarity and transparency of decision making process. [22:15:06] DanielK_WMDE: eloquence once suggested Wiki Technical Foundation with obvious intent ;) [22:15:08] matt_flaschen: what, in your mind, is archcom currently a committee of? do you see it as part of the wmf? [22:15:19] bd808: hehe :P [22:15:21] DanielK_WMDE, it's not defined right now. [22:15:47] Scott_WUaS: yes, those are the ones [22:15:48] indeed [22:16:23] it's a committee of the MW contributor community [22:16:27] okay, I think the problem question could use some more discussion, but there is evidently more interest in exploring solutions [22:16:45] I think there should be some body that "owns" MediaWiki (and maybe other open-source projects), and that is not === WMF - though inevitably closely related to it. Should it be formal "foundation" or just informal "team" - no idea. [22:17:27] Concerning "Lack of clarity on the overall technical direction of MediaWiki and the Wikimedia platform" ... what are the most relevant Wikimedia, MediaWiki and Phabricator URLs? [22:17:37] question: who runs what? whose servers are used for VCS, CI, testing environment? [22:17:39] I think the current makeup gets its credibility and expertise more from operation of Wikimedia sites than from MediaWiki as a non-Wikimedia product. we need a body like ArchCom to lead what should be deployed to Wikimedia sites [22:17:51] and that body should include ArchCom which should be guiding the decision making process, and by itself provide involvement and legitimacy solution [22:18:05] ... and which may have emerged from the helpful Wikimedia Developers Summit 2016? [22:18:30] Gabriel, Rob? [22:18:38] WMF does own MediaWiki though [22:18:42] I think a discussion of a separate foundation is interesting but not on topic for this meeting [22:18:51] Agreed, didn't mean to derail it. [22:19:08] TimStarling: that's why I say "own", not own - as in "develops and guides", not as in "holds copyright" [22:19:37] bd808: I concur [22:19:52] Scott_WUaS: the lack of an agreed vision document I could point you to is part of the problem [22:20:02] Has anyone besides gwicke dug into FLOSS governance models to a point where they would like to describe or propose a model? [22:20:02] This RFC is more about how people structure architectural decisions on a month-to-month basis. [22:20:07] SMalyshev: WMF "owns" MediaWiki in that sense. The WMF gants merge rights. [22:20:48] bd808: robla has... [22:20:52] I think the discussion about who is a member of these structures is somewhat orthogonal to the structures themselves [22:21:03] you know I suggested to Jimmy at one point that WMF not own MediaWiki [22:21:06] DanielK_WMDE: well, yes, kind of - but WMF as a whole is too big, and there's no specific team that specifically cares for MW [22:21:09] we can discuss them separately [22:21:12] but we stopped caring once WMF hired us all [22:21:12] I think legitimacy is one of the biggest problems - people can willingly go through the RfC process, or they can just build/change something, and get it deployed without ever going through a process. [22:21:20] DanielK_WMDE: which means it's everybody's problem and thus nobody's problem [22:21:26] and then WMF registered the trademarks without anyone blinking an eye [22:21:38] Rust, IETF, Python, W3C, Debian are all examples. I like the bits that gwicke has described about Rust, so he's convinced me to keep running with that as a base [22:21:50] is there anything wrong with cloning Rust's process? [22:22:25] Actually, about FLOSS governance in general, it might be interesting to hear from Lydia_WMDE with her "other hat" on: she's the present chair of KDE's governance body. [22:22:45] legoktm: agreed, and I think that's also closely related to how involved & invested people are in the process; one of the solutions we have been discussing is to broaden the involvement by creating working groups for specific areas [22:22:46] Gabriel: as I recall from the DevSummit, there were some advances in defining the "the overall technical direction of MediaWiki and the Wikimedia platform" that people transcribed in etherpad conversations. [22:22:47] there are only 15 Debian enhancement proposals, only 3 accepted [22:23:04] and DEP0 "Introducing Debian Enhancement Proposals" is not accepted [22:23:13] so I think we can rule that out as a useful model [22:23:22] WMF is the main user of MW. even when I was a volunteer dev, WMF deployment was mission critical for me - if it's needed for Wikipedia, do it and down with third party things it breaks [22:23:40] the Rust model has the advantage of a track record of productivity [22:23:45] anything else might result in a fork, just like Wikia did [22:23:50] as does the PHP, by the way [22:24:24] what are the substantive differences between the PHP and Rust models? [22:24:27] one point of difference between these different governance models is the final decision making power [22:24:31] the Rust community has a fairly well-written RFC about their governance at https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md [22:24:42] PHP RFCs are decided by voting [22:24:51] SMalyshev: can you tell us about PHP's model? [22:24:54] TimStarling: PHP's model of doing RFCs has been largely working. PHP does lack some strategic view sometimes, but tactically I think it was a success [22:25:15] a 2/3 majority of all committers, IIRC [22:25:35] DanielK_WMDE: basically, anyone can propose an RFC. There's a mandatory discussion period, which is supposed to gather support. Then the proposal can be put to a vote, which each committer can vote more or less [22:25:50] PHP doesn't seem to have concept of sub-teams deciding on a particular area. Everyoine decides on everything. That is the biggest difference from Rust I see. [22:25:59] DanielK_WMDE: the passing is 50%+1 for non-language features and 2/3+1 for language features [22:26:02] TimStarling: 2/2 of al lcommitters who voted? Or total? Total would get tricky, with lots of inactive people [22:26:13] of committers who voted [22:26:16] DanielK_WMDE: no quorum requirement currently [22:26:28] Whoa, PHP requires any RFC to be approved by a 2/3 majority vote? o.O [22:26:37] RoanKattouw, no, only touching language proper. [22:26:40] No wonder it's hard to deprecate/remove things in that code base [22:26:58] so there can be in theory and RFC decided by 3 votes (never happened AFAIK) [22:26:59] RoanKattouw: SMalyshev said that's only for changing the language itself. [22:27:03] Oh OK [22:27:04] i think that's sensible [22:27:16] in terms of scale, the Rust community last year created 331 RFCs by 127 people, of which 161 were accepted and merged [22:27:18] I see, sorry, missed that comment [22:27:19] rust RFCs are decided by the area subcommittee [22:27:30] SMalyshev: how does one get blessed as a voting committer in PHP? [22:27:31] DanielK_WMDE: 2/3 for language, simple majority for non-language (like extensions, adding/removing arguments, etc.) [22:27:36] python RFCs are theoretically decided by the BDFL [22:27:40] But I don't think democracy is a good model for making architecture decisions. I'd rather stick with wikipedia's rough consensus. [22:27:51] robla: usually by consensus by virtue of contribution [22:28:07] For example https://wiki.php.net/rfc/curl-file-upload#vote (just classes/functions) and https://wiki.php.net/rfc/void_return_type (language). [22:28:14] robla: I don't remember ever being a controversy about grating somebody committer rights, usually it's obvious [22:28:15] I gather IETF RFCs are decided by the IESG (with a ridiculously heavyweight process on top of that) [22:28:52] TimStarling: yeah, WGs->IESG->IEG->RFC Editor->done [22:29:16] this one is the most epic vote AFAIR: https://wiki.php.net/rfc/scalar_type_hints_v5 - over 150 voters. Usually it's less [22:29:23] robla: takes a decade or two? [22:29:25] DanielK_WMDE: isn't "rough consensus" our current process? [22:29:37] robla: I'm a voting committer to PHP because I took over maintainership of a tiny (~1000 line) PEAR module at one point :) [22:29:42] err...not IEG...um IAB (Internet Architecture Board) [22:29:52] legoktm: I think there is an element of do-ocracy as well, where you get your way by just doing it [22:30:15] DanielK_WMDE: PHP's one is effectively "roough consensus" except for really controversial one. I have a stats by Zeev Suraski about how many votes pass by which margin, let me find it [22:30:15] legoktm: it is, and I'd keep it. but a bit more structure (like working groups, defined last call periods, etc) could be useful. [22:30:33] SMalyshev: WMF "owns" MediaWiki in that sense. The WMF gants merge rights. [22:30:42] When I got my merge rights, I had to go to mediawiki.org and get people to vote [22:30:46] DanielK_WMDE: it *can* be quick if you know what you're doing and you have something urgent, but yes, IETF is reasonably very careful given the stakes [22:31:15] on a practical level, one proposal from the Rust community is to have the RFC discussion primarily on the task / RFC comment thread itself, in an aynchronous way [22:31:16] I think most of the people involved were WMF, but it certainly wasn't an official WMF process [22:31:53] IETF's process is very resilient against nefarious motives. One *hopes* that we don't have anyone lurking for whom we need to be suspicious of [22:32:05] * robla looks around suspiciously [22:32:13] there is a champion from the working group responsible for shepherding an RFC through the process, by making sure that relevant people are involved & moderating the discussion [22:32:53] robla: yea, IETF seems intentionally cumbersome to allow it to operate in a hostile environment. I hope we don't need that. [22:33:12] finally, once the discussion settles, a last call period (one week) is announced after consulting with the RFC owner, and the working group or core team makes a decision purely based on the online discussion [22:33:15] Rust seems like a really good "IETF-lite" boiling down of the process to essential elements [22:33:16] gwicke: and the champion needs to be an archcom member? [22:33:17] In what ways practically could the Wikimedia Dev community build on the Rust community's practices especially concerning RFCs? [22:33:33] DanielK_WMDE: or working group [22:33:57] oh ok [22:34:08] I like the subgroup idea. Both delegating decision making, and making it easier for someone to get involved in an area of their expertise. [22:34:42] do you think we're big enough to have permanent subgroups? we have enough trouble finding archcom members [22:35:03] btw, another thing that is implied for RFC in PHP that (code) RFC should either have a proposed patch or somebody who commits to develop it (in this case must be somebody everybody trusts to get it right) [22:35:28] Scott_WUaS: we could give some of their ideas a try, especially the RFC decision process & sub-teams [22:35:35] which may mean you do a lot of work and the it is declined, but also avoids "pie in the sky" situation [22:35:57] Should be easier to find subgroup members who care a lot about a particular areas than ArchCom members who need to know a lot about the whole picture. [22:36:02] Speaking only personally, I think I would be comfortable joining a sub-group that dealt with something I'm already working on, where I don't think I have time to even attempt ArchCom-level involvement. [22:36:26] in rust I think the subgroup leads are also on the central committee [22:36:31] we've had the FE Stds group for a while now. I still like the area breakdown of WikiDev '16 (insert link here) [22:36:45] so each subgroup has representation at the central level [22:36:46] TimStarling: yeah, to make sure that there is information flow between the two [22:37:06] & to identify issues that warrant a wider discussion [22:37:12] subgroups from WikiDev '16: https://phabricator.wikimedia.org/T119018 [22:38:21] I think it is important that sub-groups have a clear mandate to cover a self-contained area, which might mean that they are more project-based [22:38:57] gwicke: that makes sense to me, and then possibly build from there too [22:39:03] sub-groups could also spawn WGs [22:39:22] the distinction between working groups and areas is one of the organizing principles I like about IETF [22:39:30] the Rust community's sub-teams seem to be relatively static, though: https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md#the-teams [22:40:03] an interesting side-remark is the inclusion of a "Moderation" team [22:40:17] I am with matt_flaschen and csteipp as well reg. subgroup participation. [22:40:27] gwicke, it does mention "it may make sense to have temporary "strike teams" that focus on a particular, limited task.". I don't know if they actually do that, though. [22:40:29] https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md [22:40:35] I think we may want to agree that WGs can optionally be temporary or "temporary" ;-) [22:40:43] But I could definitely see the idea of strike teams being useful in some cases. [22:40:55] I think it's important that substantive technical discussions happen in public, not in private subgroup meetings [22:40:56] matt_flaschen: agreed [22:41:06] looks like having subject-related groups would be better for us than one all-encompassing body [22:41:50] I think a formalized two-level system of sub-committees and working groups (or task forces or whatever) would complicate things. Too much red tape. [22:41:51] TimStarling: I think the norm is to publish weekly reports from each team [22:41:58] Agree with TimStarling regarding keeping as much technical work in public as possible. [22:42:06] example: https://internals.rust-lang.org/t/subteam-reports-2015-10-23/2821 [22:42:07] TimStarling: I'm assuming all subgroup meetings would be public, just like we've done. I definitely don't think we should have private architecture meetings. [22:42:37] Perhaps we can have "standing" working groups as well as more short-lived working groups on the same level, using the same mechanisms. [22:42:50] should sub-groups be responsible then to attract as more people as possible for any given RfC? [22:42:53] discoverability and meeting overload might be a barrier to finding the public discussion of course.. [22:43:04] s/should/shouldn't/ [22:43:13] so...two tiers: ArchCom and WGs [22:43:15] ? [22:43:31] mobrovac: a more targeted outreach would be the goal, i think [22:43:50] much better then the current "if don't come to IRC at that specific time, you don't count" approach [22:44:07] DanielK_WMDE: do we really need two levels? we could just do with one [22:44:08] +1 robla [22:44:13] robla: that would be my preference, yea. As they say: "it's always *possible* to add another level of indirection"... [22:44:15] mobrovac: yes, I think that's happening both by having interested members on the group, and by the champion pulling people into RFC discussions [22:44:25] +1 mobrovac [22:44:40] I haven't heard anything that leads me to believe that Rust has a flawed model. The voting piece (ala PHP) is the main delta I'm better attuned to [22:44:46] SMalyshev: we already have one. we are discussing adding a second and maybe a third. [22:45:06] DanielK_WMDE: right, I mean just ArbCom & WG, like robla says [22:45:17] not another level [22:45:24] yea [22:46:02] robla: I'm not sure if we need voting like in PHP in MW. It's kind of weird setup peculiar to PHP having no governing structure whatsoever [22:46:07] a second level would allow us to involve more people in more focused areas [22:46:21] so in MW we could do with representative deomcracy instead of direct one [22:46:36] so... what should the size of a working group be? [22:46:45] I suspect we'll need to be careful about micromanaging the process requirements for WGs, but I agree with TimStarling that meaningful transparency is important [22:46:51] SMalyshev: you want elections for the archcom? [22:47:34] btw: this is how PHP RFC votes looked like: https://docs.google.com/spreadsheets/d/1nA_mpAkIl58nFK6ZUdB956oAk_ITAWcTfOFwYHraXyM/edit - you can see that most are very consensual [22:47:43] I have said that I would be fine with taking the decision on PHP 5.3 version support to a vote [22:48:14] a PHP RFC style vote, with voters qualified by some simple, inclusive means like gerrit accounts [22:48:20] DanielK_WMDE: that's a tricky question... ideally, it would be nice to have at least *somebody* community elected. Like in the board? [22:48:46] DanielK_WMDE: the question is - do we have active enough community to support it in a way that makes sense? If yes, then yes. [22:49:01] but in the archcom meeting just now it was suggested that we decide it ourselves instead, a committee decision [22:49:31] I think both options have their pros & cons [22:49:51] DanielK_WMDE, good question (WG size). We might want to let that come out of experience. [22:49:53] SMalyshev: most of the active community are wmf employees, which makes this a bit strange. but maybe it wouldn't be so bad. [22:49:57] That is what Rust suggests at https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md#subteams-1 . [22:50:13] TimStarling: one thing that we have learned from votes is that most drama comes from close votes. So we may want to consider having some system that filters things pre-vote (PHP doesn't effectively have one) [22:50:16] i think the vote question is of secondary importance, reaching out to the *right* people for the *right RfC* is a first stepping stone, imho [22:50:19] I think a reasoned decision based on a public discussion can be reasonably transparent & possibly lead to more consistency than voting [22:51:00] One model would also be for the elected members to appoint a number of other people they see fit. [22:51:30] while direct voting avoids bad outcomes by not giving special powers to a group [22:51:30] mobrovac: +1 [22:51:47] I just read (in the past week or so) an interesting IETF RFC about voting, or "humming" as frequently done in IETF face-to-face meetings [22:51:55] DanielK_WMDE: right. But if there's something *outside* WMF I think having representation would be nice. Or maybe even appointing somebody from, say, SemanticWiki or other major non-WMF places (no idea who :) [22:52:01] * robla goes to look up the RFC.... [22:52:40] humming IETF RFC: https://tools.ietf.org/html/rfc7282 [22:53:12] SMalyshev: +1, if the archcom and sub-groups are wmf-only then we haven't done much "outreaching" [22:54:05] weighting votes by number of decibels emitted seems a little bit sexist [22:54:05] SMalyshev: I think it probably would make sense as a long-term aspiration to have peers in MediaWiki development. Right now, ArchCom is the best we've got for ensuring the Wikimedia cluster software makes sense [22:54:09] robla: I think this is a good idea for larger groups, but am not sure if it's needed in a smaller setting [22:55:36] TimStarling: the "humming" part is probably a sexism problem. that's actually not so much the focus of RFC 7282....basically it's about quick straw polls as a tool [22:56:06] I think we do not have to decide on specific voting - if we have WGs we can let them to decide how they want to reach decision [22:56:13] ...and how to use quick straw polls effectively [22:56:30] maybe we should wrap up, considering the time [22:56:46] so...we're just about out of time. I think I owe it as an action item to sum up the questions we discussed [22:57:36] because this is the sort of thing that will inevitably leave some contingent of users and developers feeling unsatisfied, I would personally like the final decision to be decreed by the architects and to reflect their sense of the best interests of the project. [22:57:36] I think there has been a lot of support for the sub-team idea in this discussion [22:57:38] everyone else, please make your important points on the Phab task [22:57:51] for arbcom though at least straw polls would be very useful. [22:58:02] #info a lot of support for the sub-team idea [22:58:21] please comment here: https://phabricator.wikimedia.org/T123606 [22:58:24] we didn't talk as much about possibly trialing the RFC process part [22:58:43] but, I'm curious to hear your thoughts about that on the task [22:59:26] #info various kinds of voting proposed, but consensus not reached [22:59:53] anything else to get in the log before I close this off? [23:00:02] 20 seconds.... [23:00:10] I just want to stress the importance of reaching a decision quickly [23:00:20] dithering is going to send a bad signal about the efficacy of our governance model [23:00:33] ori: +1 [23:00:37] Whether on a trial basis or permanently, I think the Rust mechanism is worth trying. [23:00:50] ori: fair enough. k. sounds good. thanks everyone! [23:00:59] #endmeeting [23:01:01] Meeting ended Wed Jan 20 23:01:00 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [23:01:01] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-01-20-22.02.html [23:01:01] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-01-20-22.02.txt [23:01:01] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-01-20-22.02.wiki [23:01:01] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-01-20-22.02.log.html [23:01:09] \o [23:01:22] thanks & see you on the task! [23:01:44] did ori mean reaching a decison quickly on which governance model to pick? or that the governance model should allow making quick decisions? [23:01:55] i assume the latter. :) [23:02:02] legoktm: I'm sure all of the above ;-) [23:02:20] thank you [23:03:12] because he said this: "dithering is going to send a bad signal about the efficacy of our governance model" [23:03:39] thanks everyone for the great conversation! we can continue discussing on #wikimedia-tech