[22:01:18] #startmeeting TechCom public RFC meeting [22:01:19] Meeting started Wed Nov 8 22:01:18 2017 UTC and is due to finish in 60 minutes. The chair is DanielK_WMDE. Information about MeetBot at http://wiki.debian.org/MeetBot. [22:01:19] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [22:01:19] The meeting name has been set to 'techcom_public_rfc_meeting' [22:01:41] #topic Improving the RFC process. [22:01:46] #chair Krinkle [22:01:46] Current chairs: DanielK_WMDE Krinkle [22:01:52] o/ everyone [22:02:09] hello [22:02:11] Welcome all to a very meta RFC discussion, today about improving RFC discussions! [22:02:37] The current page that is meant to document the RFC process is at https://www.mediawiki.org/wiki/Requests_for_comment/Process [22:02:50] ...but it does not :) [22:03:02] However anyone reading that who has participated in an RFC over the last year will quickly realise that's not how we operate anymore (if we ever did) [22:03:11] I've published a draft at https://www.mediawiki.org/wiki/Requests_for_comment/Process/Draft [22:03:43] Note our main intention right now is to accurately document our current process and to also figure out what we want to improve in the next-next revision of the process. [22:03:51] #link https://www.mediawiki.org/wiki/Requests_for_comment/Process/Draft [22:04:24] one thing I'd like to see is more clear description of when you need an RFC [22:04:28] You left out the part about getting torn apart by 10 people at the same time on irc :) [22:04:31] The page is about 2-3 times shorter. [22:04:54] bd808: that'S the fun part! [22:05:11] SMalyshev: So with the renewed draft, the scope of an RFC has been aligned with the scope of TechCom. [22:05:13] DanielK_WMDE: ummm... sure. [22:05:33] Maybe including some RfC examples on the process page to give ideas on how RfC should be formatted? [22:05:43] Which is described as any change that is "strategic", "cross-cutting", and/or "hard to undo" [22:05:48] SMalyshev: good point. I think there is a pretty good description of scope in the charter, though. Anything technical that is cros-cutting, strategic, or hard to undo. [22:05:52] and also what is the relationship between RFC and actual implementation - when you submit an RFC, are you supposed to have somebody committed to implementing it? [22:06:04] With +2'ers being the people that should self-police this when they do code review. [22:06:04] #info one thing I'd like to see is more clear description of when you need an RFC [22:06:12] #info Maybe including some RfC examples on the process page to give ideas on how RfC should be formatted? [22:06:16] Krinkle: I think getting rid of on-wiki RfCs would be a mistake. Some of the longer ones are much harder to review on phab, looking at diffs is not easy [22:07:08] legoktm: It's a requirement for each RFC to have a phab task, from the start. However, it's not hard required for the text to be in the task description, it could be a link to elsewhere, no problem. [22:07:17] Zppix: i like that. A few clear examples of changes that require an RFC, and a few that don't, could also be helpful. [22:07:19] I have to disagree with legoktm, having RfCs in one central place is easier to track proposed/in-progress/etc rfcs [22:07:22] legoktm: you can always have a design paper on wiki. it's just not an integral part of the process [22:07:26] For what its worth I think that RFCs have been moving faster and faster over time which is good [22:07:37] I don't think we should pin down a hard requirement for it to be phab or wiki based on a set size, but I wouldn't mind adding text that says it's okay to link to a wiki page if preferred. [22:07:37] Krinkle: Right. But https://www.mediawiki.org/wiki/Requests_for_comment/Process/Draft#Create_a_proposal doesn't mention that. [22:07:41] legoktm: the *process* is on phab. the *text* can be wherever [22:07:51] DanielK_WMDE: I agree. But that's not what the draft says. [22:07:58] but the question from SMalyshev is key. Many Foundation teams don't think of it as a useful or required step [22:08:10] legoktm: Yeah, I made a point to remove any mention of the RFC wiki pages, but I wouldn't mind adding back a bit to say it's okay for the text to live there, would that be good? [22:08:13] what could use more guidelines IMO is at what phase to have an RfC [22:08:19] #info Krinkle: I think getting rid of on-wiki RfCs would be a mistake. Some of the longer ones are much harder to review on phab, looking at diffs is not easy [22:08:43] IMO there has been a lot of "I have a problem but only vague ideas how to solve it; let's have an IRC discussion!" recently [22:09:06] tgr: Right, so RFC != IRC discussion. [22:09:10] #info [14:07:41] legoktm: the *process* is on phab. the *text* can be wherever [22:09:29] and then it turns out to be a waste of time because timeboxed IRC chat is good at vetting an implementation proposal, but really bad at coming up with one [22:09:37] Nor is an IRC discussion required for every RFC. Although any participant (incl author and techcom) can request one if you want one. [22:09:55] tgr: i think it's ok to have "vague" RFCs for field narrowing, as long as this is made clear. and more concrete rfcs should be prioritized. [22:09:58] tgr: so good point that RFC should include a (reasonably baked) proposal for a solution? [22:10:00] Krinkle: Yeah. "Longer and more detailed proposals can be documented on-wiki under Requests for Comment/blah" or something. [22:10:05] <_joe_> tgr: I think that's hard to determine a priori. But I would say that having poked at the problem, as in having at least a stub implementation should be desirable in general [22:10:16] Krinkle: I have heard that a lot. I have yet to see an RfC which did not end with an IRC discussion, even when it felt unnecessary. [22:10:18] <_joe_> legoktm: +1 [22:10:28] #info Let's document that it's still okay to put long RFC texts outside Phab with a link (e.g. on mediawiki.org) [22:10:54] DanielK_WMDE: to be clear I think RfCs early in the planning process are good things; IRC discussions not so much [22:10:55] <_joe_> #info < tgr> what could use more guidelines IMO is at what phase to have an RfC [22:10:55] DanielK_WMDE: only mentioning it because you said "wherever" - it's not OK for documents to be in a Google Doc. The only options should be on-wiki or in a phab task. [22:11:03] I think a clear priorty system should be implemented within the RfC process maybe giving examples of what RfCs are more likely to be of higher priorty vs low priorty [22:11:06] tgr: i guess it's currently unlcear how to request Last Call without an IRC meeting [22:11:14] SMalyshev: An RFC will need a clear problem and solution before it can be approved, but there is not currently any hard requirement for creating the RFC task. [22:11:45] legoktm: i tend to agree, but I'd like to hear your reasoning [22:12:04] WE're looking to gather ideas for what should and shuld not be a hard requirement, but given that we have not been enforcing any requirement in particular, I don;t think we should document these now, but we'll do that as a possible next step. [22:12:13] Krinkle: well, the problem part should be, i think [22:12:33] DanielK_WMDE: Yeah, but that'll come naturally as part of the review and TechCom feedback part of the process. [22:12:34] DanielK_WMDE: People shouldn't be forced to use non-free software/proprietary systems to participate in the MediaWiki architecture process. [22:12:35] <_joe_> #info An RFC will need a clear problem and solution before it can be approved, but there is not currently any hard requirement for creating the RFC task. [22:12:43] ok, so it's ok to propose RFC that has problem but no clear solution (yet)? [22:12:44] DanielK_WMDE: Google docs are pretty much unreadable when you have a nontrivial number of comments [22:12:50] SMalyshev: Absolutely! [22:12:56] got it [22:13:03] SMalyshev: Most RFC tasks start with a vague problem statement and zero or more solution ideas. [22:13:26] Then they sit in the backlog until a clear problem is defined. Or an IRC meeting is requested to help define the problem clearly. [22:13:27] #info The only options should be on-wiki or in a phab task. People shouldn't be forced to use non-free software/proprietary systems to participate in the MediaWiki architecture process. [22:14:05] Then they go to under discussion while we gather and iterate on the proposed solutions. Again, an IRC meeting can be requested to help find what solution is best, or if coming short on a good solution. [22:14:14] Krinkle: so maybe a clear issue should be required before opening an rfc task? [22:14:48] Zppix: We can't stop anyone from creating an RFC task, so the requirement wouldn't apply to that part of the process. [22:15:11] Krinkle: well, we can reject rfcs and drop them off the board [22:15:17] But we can consider documenting some aspects TechCom would require each RFC to address before we can review it ("Under discussion"), and that without it, it will be in Backlog. [22:15:35] DanielK_WMDE: Right, but more likely we'd move them to Backlog asking to define the problem better. [22:15:52] unless we disapprove of the underlying idea (which is unlikely, if we dont' yet know what that is) [22:16:16] we have dropped a few things that were out of scope in the past [22:16:30] Yeah, good point. [22:16:33] #info But we can consider documenting some aspects TechCom would require each RFC to address before we can review it ("Under discussion"), and that without it, it will be in Backlog. [22:17:11] Wouldnt keeping tasks that arent up to requirements in backlog make the backlog harder to navigate? [22:17:46] Zppix: The Backlog is dedicated to only RFCs that are currently incomplete or blocked. [22:17:57] Krinkle: should we require an RFC as part of the regular sign-off requirements for new technologies? or is the requirement "TechCom review", not necessarily an RFC? [22:18:10] It's a parking space for RFCs where the people working on it are not yet ready to ask TechCom for review [22:18:23] But we encourage people to do tag TechCom-RFC so that we're aware of it as early as possible. [22:18:32] Zppix: the alternative is basically to have no backlog column [22:18:53] DanielK_WMDE: or have a dedicated column for that situation? [22:19:00] Zppix: That's Backlog. [22:19:04] :) [22:19:31] one thing that I would like to be regulated stricter is strategic changes of the "boiling the frog" kind [22:19:58] Krinkle: we need some criterion for dropping stuff from the backlog, though. otherwise, it will just keep accumulating dead wood [22:20:02] <_joe_> DanielK_WMDE: can you better define what you mean by "new technologies"? [22:20:24] ie. when something happens in small steps and there never is a single point where an RfC feels really appropriate, but taken as a whole it is strategic and hard to undo [22:20:25] DanielK_WMDE: Yes, and we also need to document that we can decline RFCs out of scope, currently let's left implied, forgot about that :) [22:20:27] _joe_: an exact definition would be tricky... [22:20:39] https://en.wiktionary.org/wiki/boiling_frog [22:20:42] <_joe_> DanielK_WMDE: and without it, an exact response is tricky :) [22:20:57] #info Document that RFCs can be declined if out of scope. [22:21:09] <_joe_> DanielK_WMDE: I would say: a new microservice should go through the rfc process [22:21:09] tgr: do you have an example you're thinking of? [22:21:22] _joe_: basically, anything that would require a security sign-off and/or a legal sign-off [22:21:30] <_joe_> any significant change to the architecture should, in fact [22:21:48] #info one thing that I would like to be regulated stricter is strategic changes of the "boiling the frog" kind [22:22:13] _joe_: i agree, yes [22:22:18] legoktm: mobile support in MediaWiki not being available without a bunch of node.js services that were never really meant for third-party usage, for example [22:22:47] tgr: not to put too fine a point on it. ;) [22:23:25] #info <_joe_> DanielK_WMDE: I would say: a new microservice should go through the rfc process. any significant change to the architecture should, in fact [22:23:33] tgr: it depends on whether there is harm in the pattern spreading and whether the pattern being everywhere would make it in-scope. For example most coding conventions, even if applied everywhere at once or slowly, are out of scope. [22:23:36] https://www.nczonline.net/blog/2015/05/14/the-bunny-theory-of-code/ - applies here [22:24:02] #info boiling the frog = when something happens in small steps and there never is a single point where an RfC feels really appropriate, but taken as a whole it is strategic and hard to undo [22:25:04] Different question: is "in progress" vs. "under discussion" a useful distinction? [22:25:17] No [22:25:26] In general, given code conventions and a strive for consistency from code reviewers, a new pattern emerging that diverges from current strategy and is incompatible with things, should be discussed first or that one case changed before landing to be consistent and discussed separately. I've seen this quite often where code is doing something differently because the author doesn't like the current conventions. [22:25:27] They are essentially the same no? [22:25:34] my thinking was that code written for an "in progress" RFC can be expected to be merged, possibly with some adjustments [22:25:38] At which point Code-Review should result in the pattern being restored and a separate discussion started. [22:25:52] while code written for "under discussion" would be required to be marked as experimental [22:26:01] <_joe_> Krinkle: coding conventions as in "use spaces not tabs", or even conventions about how to organize code in projects? [22:26:22] DanielK_WMDE: It's not clear to me how an RFC that is not approved can have code merged in any circumstance. [22:26:25] DanielK_WMDE: i see under discussion as in progress and vice versa [22:26:26] _joe_: the latter may impact releng [22:26:28] Does this not really mean we should've simply approved it already? [22:26:48] tgr: for that example, I think _joe_ said earlier that any new service should go through an RfC review, in which case maybe it could have been stopped earlier [22:26:51] RFC process != nit pick code review or applying of orthogonal policies and general code guidelines. [22:27:20] Krinkle: i didn't mean to say the code can be expected to be merged before approval. it's just that approval seems likely, but details remain to be figured out [22:27:51] I think that answers the overall question :) IMHO that means the process is being short-circuited in ways it shouldn't. [22:28:16] <_joe_> legoktm: any new microservice we introduce is by definition hard to undo and widely impacting, IMHO [22:28:19] Although I suppose experimental code could be merged behind a feature flag, if all involved agree it can easily be removed or disabled at any point and not enabled by default. [22:28:29] But I'm not sure that state needs to be reflected in the RFC process. [22:28:35] legoktm: so there is extension X which is the de facto way of mobile support in MediaWiki, and service Y which X can use to add various bells and whistles [22:28:37] what do we mean by new microservice? [22:29:00] Krinkle: perhaps such cases are better addressed by breaking the RFC up into smaller RFCs. So progress can be made before the whole thing has been finalized. [22:29:08] Yep. [22:29:10] i.e. would SPARQL engine be something we'd want RFC for? [22:29:24] then more and more features are ported over from other MediaWiki extensions to Y, and at some point it's not really "bells and whistles" so much as "not really useful without it" [22:29:53] or using existing SPARQL engine for storing new things (say I wanted to load watchlists into SPARQL (I don't but for the sake of example)) [22:30:05] SMalyshev: Deploying SPARQL should not happen without an RFC, but it might not need a dedicated RFC. This could be part of a larger RFC and discussed as such. Especially because it's not a solution in itself, but part of a larger process, right? [22:30:06] at no point in the process is it fair to say that the people doing it were wrong by not starting an RfC, the individual changes are not so large [22:30:35] SMalyshev: introducing the service should probably have been an RFC... using it for more stuff - depends on the stuff. in that, the calling code is the issue, not the service. [22:30:55] Krinkle: well, kinda, having SPARQL server running is of course not ultimate goal, the ultimate goal is to load some data there and query it. [22:31:03] <_joe_> tgr: actually, if a new service with its own api and call flow and all is created, in my opinion it *should* go through the RFC process [22:31:06] SMalyshev: Yep. [22:31:43] DanielK_WMDE: that's what I am trying to figure out - where is the point one needs RFC... what if there's no calling code, just open API? What if there is calling code in some extension? [22:31:59] tgr: .. and following from _joe_ .. if the service is slowly but surely being recycled into something else, that's a product decision that should probably involve communication more widely and not happen secretly, we're assuming good faith here. [22:32:01] _joe_: I agree, but the point here is that the role of the service changes gradually from optional enhancement to dependency [22:32:04] what if that code is now moved to core because more extensions want to use it? where is the point we need RFC? [22:32:23] an initial RfC would not help with that [22:32:35] and I'm not just inventing things, that kind of thing happens with search more and more [22:32:40] SMalyshev: IMO a rfc to move to core is needed [22:33:05] SMalyshev: when an extension deployed on the wmf cluster starts using a new service in new ways that is cross-cutting, strategic, or hard to undo, it needs an RFC. e.g. if that means the extension won't work in a vanilly LAMP environment [22:33:20] anyway it was just an example, the point is that sometimes the long-term vision would require an RfC and the actual changes probably not [22:33:25] *vanilla [22:33:40] <_joe_> tgr: well I suppose any significant change in the call flow of parts of our assets is a "large architectural change", but defining what's significant is hard [22:33:58] #info <_joe_> tgr: well I suppose any significant change in the call flow of parts of our assets is a "large architectural change", but defining what's significant is hard [22:34:05] DanielK_WMDE: "strategic" is kinda hard to define... let's say we moved Wikibase search from SQL to Elastic - should we had an RFC on that? [22:34:07] <_joe_> tgr: I'd prefer to assume good faith and suppose people will not try to dodge or trick the process [22:34:26] _joe_: introducing dependencies on new services, or addign significant load to existing services, or breaking compat with a platform would all qualify [22:34:53] it's not runnable on vanilla mediawiki (the elastic part), and it's looking pretty strategic to me as for capabilities it affords... but I have no idea, honestly, wthere it needs rfc... [22:35:12] i don't think tgr is saying not agf .. but i think asking what do you do when product vision / needs change incrementally in a way where the full picture is a substantial change .. but no increment is. [22:35:16] _joe_: the point is that the people who do the step-by-step changes feel (entirely reasonably) that those are small steps and don't need an RfC [22:35:23] Just to clarify here to keep the conversation on-topic, the scope of TechCom and communication channel and product lifecycle for Wikimedia Foundation is mostly orthogonal here. And it seems to me that is not something TechCom can solve. We've clarified our requirements, and ultimately the CTO makes the decision that that is a required part of the process. [22:35:24] SMalyshev: good question - for wmf, this isn't really cross-cutting. But it potentially breaks compat with the LAMP stack. [22:35:38] and we have pretty much limited RfCs to implementing things [22:35:46] If people find ways to slowly bypass that process, that is a social issue between product teams and the CTO. [22:35:52] like, basically everything in an annual plan is RfC-worthy [22:36:17] #info like, basically everything in an annual plan is RfC-worthy [22:36:20] but the unsaid assumption is that planning happens via top-down decisionmaking and is exempt from the RfC process [22:36:21] tgr: good point :) [22:36:27] DanielK_WMDE: yes. also, I'm not sure whether vanilla (non-elastic) search works in wikidata at all of how it looks like now... we haven't used that for ages and I'm not sre what's going on in there really [22:36:41] ( I don't mean prefix but fulltext one) [22:36:47] to clarify: does the RFC process apply (1) only to changes to MediaWiki, (2) changes to software that touch or affect MediaWiki, (3) all software engineering work at WMF, or some combination thereof or something else? [22:36:48] <_joe_> tgr: I explicitly said at the last dev summit something needs to happen in that process :) [22:37:06] although halfak|net_derp has been trying to get that annual process changed and at least more public .. if i understand correctly [22:37:06] so, no idea whether I need RFC here at all [22:37:11] mdholloway: All software maintained or deployed by Wikimedia Foundation. [22:37:14] and the implementation of that plan is where RfCs supposed to happen, except that often not because it happens in small steps and those steps are not so interesting in isolation [22:37:19] SMalyshev: i wrote it :) it should work. very very badly, but it should work :) [22:37:19] <_joe_> tgr: but I don't think saying annual planning is top-down is fair. I surely had a lot of input into it [22:37:20] Krinkle: thx. [22:37:43] mdholloway: Mostly detailed at https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Charter - which functions as an extension of WMF's CTO. [22:37:44] DanielK_WMDE: ok, I trust you (and also accept your self-nomination as maintainer of that code ;) [22:37:58] *cough* [22:38:51] SMalyshev: it's just getTextForSearchIndex(), which uses FingerprintSearchTextGenerator. Which has Thiemos name on it :) [22:39:03] <_joe_> tgr: I would say the decision wether the WMF should work on a new mobile website can be top-down, how to implement said website should not be [22:39:27] so, more generically, if we did things the Right Way (TM) we probably should have had an RFC somewhere on the way where we decided how to search Wikidata? [22:39:28] or not? [22:39:35] <_joe_> and how you implement it should be something you decide in concert with the rest of technology, via this process [22:39:35] SMalyshev: For mediawiki core, search has always been quite minimal (SQL-only). Removing support for that, for example, would be a MediaWiki platform product decision, which might need to involve TechCom as well. [22:40:01] SMalyshev: For Wikidata, it's a bit more tricky. given Wikidata being maintained by WMDE, it's standalone product is not in our scope, but it's deployed state is, technically speaking. [22:40:05] mdholloway: all software used by wmf to provide public services. this excludes e.g. development tools, but includes CI, and certainly all public APIs. [22:40:31] SMalyshev: So I'm not 100% sure on whether removing support for SQL in Wikibase search is in scope for TechCom. [22:40:35] DanielK_WMDE: Thoughts? [22:40:50] We're talking from the perspective of: It happened, should it have been an RFC? [22:40:53] DanielK_WMDE: thx, makes sense [22:41:02] Krinkle: oh, fun, but let's say it was extension that is in-WMF? that would be RFC, right? [22:41:15] <_joe_> Krinkle: *if* we treat wikibase as an upstream software we install, then no [22:41:25] Krinkle: undecided. it's not corss-cutting. it's not necessarily hard to undo. it is strategic only wrt 3rd party use of wikibase. [22:41:34] Exactly. [22:41:35] <_joe_> but that's not a very wise way to see wikibase IMHO [22:41:35] _joe_: but we don't really. I commit there all the time, especially lately [22:41:43] Strategy of third-party use is in-scope for WMF-maintained code for sure. [22:41:52] Including code we maintain through CR-mostly with volunteer contributions. [22:42:08] _joe_: wikibase is controleld by wikimedia, so no, it's not upstream. [22:42:44] Is this RFC process the "WMF prod" process or the MediaWiki FLOSS process? [22:42:47] There is also the argument of whether or not thirdparty use is supported in the first place, which is again a product decision, not TechCom. [22:42:52] in my mind, "wikimedia" includes WMDE [22:42:59] For example, WikimediaMaintenance and WikimediaEvents are WMF-maintained extensions [22:43:00] +1 bd808 [22:43:07] but we don't support third-party use of those. [22:43:09] bd808: both [22:43:09] +1 DanielK_WMDE (re WMDE is Wikimedia) [22:43:41] <_joe_> bd808: the techcom -related one, so kind-of both? [22:44:29] Krinkle: so, we say that the 3rd party version of "cross-cutting" is a product decision? and if the product decision is that we should support 3rd parties - then the technical change needs an rfc? [22:44:33] <_joe_> Krinkle: I wanted to propose to create guidelines on how to write RFCs - but I guess that's for a later meeting? [22:44:59] SMalyshev: I think in the end, things like SQL search support is a product decision given it is third-party only, and thus its strategy is inter-dependent on the product roadmap, which for WMF we communicate internally, and for WMDE we communicate with WMDE. Same-same :) [22:45:28] _joe_: Yeah, definitely would want that as well, but given we dont enforce those curerenty, that would be the next step after this. [22:45:40] <_joe_> Krinkle: ack [22:45:43] Krinkle: i think RFCs for changes that mainly affect 3rd party users are useful if affected stakeholders actually take part in the discussions. i'd like that, but i don't know how to make that happen. [22:46:15] DanielK_WMDE: Yeah, I think in general we do commit to our open source projects being re-usable for the public (unless stated otherwise for wmf-specific things). [22:46:49] Krinkle: maybe we need a "3rd party friendly" version of the process for some cases. with longer wait periods, wider communication, etc [22:46:51] But being re-usable and how complete the core feature-set is are different questions entirely. E.g. whether Wikibase comes with search by default for MySQL-only installs, who decides that? [22:47:10] Krinkle: product [22:47:12] Or e.g. the removal of Postgres support. [22:47:14] in the case of wikibase, Lydia [22:47:16] Right, so not in our scope. [22:47:25] But isn't it also strategic? [22:47:30] (which is in-scope?) [22:47:35] "3rd party friendly" really does imply that this is less about MediaWiki and more about Wikimedia [22:47:43] which is fine, but maybe should be stated [22:47:57] Krinkle: not strategic wrt our tech platform [22:48:05] bd808: The RFC process is not MediaWiki-specific [22:48:18] Krinkle: well, actually, the incentive for dropping PostGres could be a tech strategy (cutting dead wood) [22:49:14] So it could happen that we have an RFC on dropping postgres for technical reasons. and then get told we have to keep it for reasons of product strategy. [22:49:17] that *could* happen. [22:49:22] <_joe_> bd808: are you asking if the RFC process applies also to MediaWiki-related product decisions [22:49:25] <_joe_> ? [22:49:36] Krinkle: sure, but the idea of a "3rd party" implies that there is a "1st party" to be distinct from and that 1st party is ...? The Wikimedia movement with the Foundation acting as its proxy? [22:49:56] bd808: essentially, yea [22:49:56] so this is how I perceive the status quo [22:49:59] bd808: yep [22:50:10] I just saw a lot of mention of upstream and 3rd party and I think it would be nice to be clear [22:50:11] * DanielK_WMDE always wonders who the 2nd party is [22:50:22] product decisions can have consequences in technical maintenance costs and social maintenance costs [22:50:52] DanielK_WMDE: the users :) [22:50:55] (the first being that e.g. code becomes harder to debug and the second being that we end up with an ecosystem that's less interesting for volunteers so we have less of them) [22:51:17] But yeah, it's a bit odd how its named [22:51:24] 2nd part is users of the 1st party [22:51:29] the RfC process is being used as a guard against prouduct decisions unwittingly incurring large technical maintenance costs [22:52:36] As I understand it, for large product decisions, there is a lifecycle or pipeline of sorts (for WMF at least), which involves at different points Legal, Security, Community Advocates, Performance, and also CTO/TechCom. [22:52:45] tgr: not *just* product decisions. more often, technical decisions. but yes [22:52:47] social maintenance costs seem to be considered off scope, it doesn't look like most product decisions consider them, and there doesn't seem any other place in our decisionmaking process where they would e considered, either [22:52:57] #info the RfC process is being used as a guard against prouduct decisions unwittingly incurring large technical maintenance costs [22:53:07] So the product decision is not "hosted" by TechCom, but it is part of that larger pipeline. [22:53:28] <_joe_> tgr: I would frame it a bit less negatively. The RFC process should be used to harmonize the technical decisions and maintain the overall architecture sane [22:53:37] Krinkle: is this pipeline actually documented somewhere? publically? [22:54:13] oops [22:54:17] five minute warning [22:54:18] time fleis [22:54:24] DanielK_WMDE: I believe it's been worked on by various people who held the VP of product / CPO roles at different times, but no one version has been marked as complete. [22:54:24] <_joe_> bd808: let me put it this way: the RFC process regards the Wikimedia movement for sure, but I can see us having RFCs about software we develop (not just mediawiki) that could be interesting for people outside of the movement [22:54:30] Most of the drafts were maintained on mediawiki.org, though [22:54:56] https://www.mediawiki.org/wiki/WMF_product_development_process/Proposal [22:55:00] Krinkle: does any of them mention TechCom?... [22:55:00] https://www.mediawiki.org/wiki/Software_development_concepts#Product_Lifecycle [22:55:13] _joe_: I did not mean to say that is the only use of the RfC process. My point is that social issues (like loss of userbase due to technical choices that are hostile to 3rd party users) are currently seen as off scope for the RfC process (I think?) and there is no other venue for them either [22:55:31] DanielK_WMDE: https://www.mediawiki.org/wiki/WMF_product_development_process [22:55:44] (bravely dipping my toe in an IRC discussion) I agree that it would be good to find a way to get 3rd parties more involved in the RFC process for those RFCs that affect them (e.g. PostGres support). I will do whatever I can to help make that happen. [22:55:45] DanielK_WMDE: No, but then again the drafts are from 2015. [22:56:13] There is a status quo that involves the CTO, but it's not documented as far as I know (if it is, it'll be public, i havent' seen any of these drafts on non-public platforms) [22:56:44] #info I agree that it would be good to find a way to get 3rd parties more involved in the RFC process for those RFCs that affect them (e.g. PostGres support). I will do whatever I can to help make that happen. [22:57:18] CindyCicaleseWMF: we have people for talking to the tech community these days (CommTechCom)... but not really for talking to 3rd party wiki owners. [22:57:36] tgr: I'd like to believe that open-source friendliness is part of the strategic goal that TechCom has in its scope. [22:57:50] I'd certainly use it as weight in an RFC where needed. [22:57:54] <_joe_> tgr: well if we think dropping a feature is a product decision, I would expect them to have their public decision process. But AIUI the point you're making is that a decision about a feature is seldom a "product-only" one. I agree, but I would have a hard time synthetizing it in some rules [22:58:38] But if a decision is of the form, deprecate extension X entirely, or remove service X, then there isn't really a technical involvement there, unless it is cross-cutting. [22:59:16] The same way TechCom doesn't introduce new products, we can't (and shouldn't) be able to keep them either. [22:59:57] Krinkle: and neither to kill them? [23:00:04] Krinkle: we have a lot of decisiions like "replace extension X (reusable outside WMF) with service Y (non-reusable)", and those usually don't result in RfCs, because as you said, there isn't much technical component [23:00:27] ok, time is up... any last words? [23:00:29] but the social component is nontrivial [23:00:38] tgr: That depends, service Y would need an RFC, and as part of its drafting, we'd make sure it doesn't get too tightly coupled. [23:00:45] That's just good design in general, and for our future selves too [23:00:46] <_joe_> tgr: well, I would argue the decision was significant before, when that service was created [23:01:17] i'm closing the meeting here. [23:01:32] Although I can see how a dependency on Restbase or Parsoid but be interpreted as making it wmf-specific, is that what you mean tgr? [23:01:32] please continue the conversation in #wikimedia-tech [23:01:37] #endmeeting [23:01:38] Meeting ended Wed Nov 8 23:01:37 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [23:01:38] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-11-08-22.01.html [23:01:38] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-11-08-22.01.txt [23:01:38] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-11-08-22.01.wiki [23:01:38] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-11-08-22.01.log.html [23:01:42] Thank you all! [23:01:59] Krinkle: lots of useful input, I think! [23:02:04] Yep