[21:00:57] #startmeeting TechCom Office Hour [21:01:03] I figured we should log this :) [21:01:21] oh but the bot is asleep [21:02:08] sigh [21:02:12] TimStarling: could you get the bot working? [21:03:27] at some point we should have TimStarling pass down this holiest of all knowledge - the bot kicking [21:03:33] https://wikitech.wikimedia.org/wiki/Tool:Meetbot [21:03:48] except instead of "become meetbot" I use "sudo become meetbot" [21:05:20] #startmeeting TechCom Office Hour [21:05:20] Meeting started Wed Apr 17 21:05:20 2019 UTC and is due to finish in 60 minutes. The chair is KateChapman. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:05:20] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:05:20] The meeting name has been set to 'techcom_office_hour' [21:06:22] yay! our first office hour! [21:06:28] now, where are the guests?... [21:06:28] \o/ [21:06:45] \o [21:06:46] fashionably late, perhaps? [21:06:48] KateChapman: duesen: it would be helpful perhaps to give a short intro? [21:07:00] for context to ppl, etc [21:08:31] could do, I just don't know whether I'm talking to an empty room :/ [21:09:16] I'll do an intro as soon as any non-techom-member shows up and says something :) [21:09:20] well you could tag the intro with #info so it is in the minutes :) [21:09:24] * mobrovac sent a nudge email to wikitech-l [21:09:30] hi [21:09:48] hey bill! good to see you here! [21:09:50] duesen: there are 225 ppl in this room currently :P [21:09:52] okay let's not overwhelm Bill with our excitement at his attendance :p [21:09:55] LOL [21:10:24] I have a question. What areas do the Committee think we have too many / don't have enough activity in? What RfC would you love someone to bring, if only they had the time? [21:10:57] oh allright. there is people here afterall [21:11:19] o/ [21:11:26] i'll do a very brief intro, and then we can try to find an answer to James_F's question [21:11:34] So. This is the first TechCom office hour. [21:11:49] o/ [21:11:57] This isea is to provide a place where people can ask TechCOm about stuff [21:12:21] About TechCOm itself, about ongloing RFCs, about the RFC process, or other things [21:12:33] I have no grand plan other than being here and talking to people [21:13:24] Question for TC: we've seen lately a bunch of architecture and other guidelines published/initiated, which is good. Would TC also lead an effort to make our existing code more aligned with these principles? [21:13:51] if so, how exactly would that happen - the effort may be non-trivial and risky [21:14:00] James_F: my personal take on your question: if I had a concrete idea i thought someone should rbing an RFC on, i'd probably do so myself. What we do have is far too many stalled RFCs in the backlog. Staleld for lack of resources, or need for a product level decision, or just lack of interest, or lack of time [21:14:23] * James_F nods. [21:14:26] there is a lot of interesting ideas there waiting to be picked up (and perhaps some wiating to be buried) [21:15:14] mobrovac, milimetric, other techcom members... other thoughts? [21:15:45] So there aren't areas you think are under-served and we should be driving up interest for more RfCs, like extension flexibility or whatever? [21:16:52] I think the committee's interests are mostly reflected in the RFCs we write [21:17:03] Right. [21:17:18] but yes, there are a lot of RFCs in the backlog, some with extremely brief descriptions [21:17:31] Thank you! [21:17:41] yeah, if anything there are almost too many RFCs written by tech com, but I guess there's nothing wrong with it [21:18:28] Shall we move on to SMalyshev's question, then? [21:18:30] and I'd of course love to see more backlog cleaning [21:19:06] Can I suggest something? I know we had tech meeting today but this is a horrible time to pick if you expect anyone in the UK/Europe to come. Maybe try a bit earlier even 7pm wouldn't be bad but it's 10:18pm for us in the UK [21:19:22] Lots of us are in EU [21:19:34] we are doing an alternating biweekly schedule now [21:19:43] RhinosF1: It's the usual time for this meeting, as it's the least-worst time for everyone along with the other time. [21:20:02] RhinosF1: it'S an hour later for me :) I do see your point, we have been trying to find a better time for this meeting before, and failed [21:20:18] well, we ahve an alternative slot now, every other week - which would be 7am in the UK [21:20:22] nut sure that'S better :) [21:20:57] mdnight here, yeah it's tough [21:21:16] SMalyshev: we do have some time allocated in TEC13 for improving code health, the core platform team is doing some work along those lines [21:21:17] #info the meeting time sucks for pretty much everyone [21:21:43] 7am is a bit better but most of the time I wouldn't be here at this time (I got caught up in something). I'd rarely get one this time but I'll regularly get a bit of time in at 7am UK but probs not super active [21:21:59] #info techcom doesn't feel a lack of rfcs in specific areas, more a lack of resources to follow through [21:22:02] not everyone, but probably does suck for non-US folks [21:23:04] SMalyshev: the problem with techcom leading the effort is that techcom doesn't have any resourcing power. the best we can do to push stuff is to, well, make policies. [21:23:36] TimStarling: ok that's for core, what about non-core parts? Everybody for their own kingdom? [21:23:44] I get with the US thing, It's late afternoon for you guys but a lot of areas will be quite late at night or early in the morning [21:23:52] As tim says, the core platform team has taken on several projects to make our code base compliant with the ideals we write into these policies [21:24:09] great [21:24:39] RhinosF1: the other slot is late at night in the US. We try to alternate. [21:24:45] you're saying TechCom should encourage teams to work on tech debt? [21:25:15] the thing about tech debt in core is that it affects a lot of teams [21:26:20] I'm not sure what Tech Meeting is but that's 3pm UTC in summer and 4pm UTC in winter and that gets enough most of the time. What's that like for everyone? [21:26:27] TimStarling: well, I don't have a ready proposal, I am just wondering about the gap between the vision we have in principle and the code we have to deal in practice, and it seems to me that day to day reality for the teams is that this question is not raised very often [21:26:34] SMalyshev: I think the key is really your second question: "hos is that going to happen"? How, if not by making policies, can TechCom encourage teams to improve test coverage, or scalability, or localization? [21:26:57] I see SMalyshev's point also in relation to issues that are local to an individual code base. I cant think of a great example right now, but let's say php serialize() anti-patterns and dependency injection / services container. The question could be: When should a team be expected to refactor their code to adopt these principles? [21:27:06] and TC may have a role in elevating this question to the level where it is considered equally with developing new stuff by people that do have resourcing power [21:27:34] RhinosF1: for Tim, that's in the middle of the night :) [21:28:15] Krinkle: yes, when and would they be given resources to do it? If it requires choice between new feature and tech debt, would the latter be resourced? [21:28:20] For me personally, I've always considered maintenance a non-negotiable part of development. As I understand it, some engineers in our org struggle to provide estimates in this way, and/or separate "development" from "maintenance" in a way that makes this difficult. [21:28:37] That is of course not a question for TechCom, but I am happy to continue answering it in my own perspective. [21:29:06] IMHO, there are two types of RFCs, one for example to unblock a team to move forward (decide on what technologies to use for example) or the ones that make a principle. The former gets implemented by design because the team asked for it, the latter is a different story [21:29:12] We have this goal thing - implement this functonality, improve this metric, and so on. So development of this kind is easy to measure [21:29:21] refactoring is hard to measure [21:30:08] SMalyshev: I'm currently working on (better) ways measuring code quality. The mid-terms gioals say we should also measure developer productivity and satisfaction. [21:30:11] I suppose it is hard to please everyone, I guess we needed Tim as well today. Might be best to have someone look into it and get people to suggest a new schedule that rotates times circling round one that suits Asia/Oceania, one for Europe and One for IS [21:30:13] US [21:30:20] That should provide the arguments to get the resources. [21:31:09] This isn't meant personal in anyway, but a common phrase I hear is: If you can give reasonably accurate estimates for new developments, then something is wrong. Either 1) it wasn't actually development, but configuration, or 2) you're doing the same as something that was done before, which usually indicates something isn't being re-used as it should. [21:31:14] Of course, it's always easier to get resources for "shiny" things. But well paved roads and workign appliances are thigns people appreciate and pay taxes for. the same logic should apply here [21:31:18] and we are lobbying for that [21:31:54] RhinosF1: we have two different times now, perhaps we need three. [21:32:24] Krinkle: I like that. a lot :) [21:32:44] SMalyshev: While we can only informally encourage engineers to consider refactoring part of their job. We do have a more formal ability to require it for areas where an RFC is required for an upcoming change. For example, for a new product that makes use of X, we can say X must be up to our current standards before we can move forward, and not approve a compromising proposal. [21:33:18] so enforcing no use of php serialize() or requiring DI in an existing feature is not something we can do, but for anything new or a cross-cutting change, we can (in theory). [21:33:48] Krinkle: can I make that a quip? [21:33:54] Duesenberg, I think 3 might be best. [21:33:56] duesen: which one? [21:34:06] Duesen, %^ [21:34:19] * RhinosF1 should not be awake [21:34:30] "If you can give reasonably accurate estimates for new developments, then something is wrong" [21:34:44] I got that from Kevlin Henney. [21:34:53] I don't care :) [21:34:58] okay. then. [21:35:49] we have two different times, but only one Tim. [21:36:59] We clearly need to hire an EU-based Tim. [21:37:40] we just have to get him to move to the UK :P [21:37:54] * duesen is trying to come up with an #info that would summarize the answer to SMalyshev [21:38:03] A while back I proposed informally that there should perhaps be an expiry date on RFCs of type "feature implementation" (extension, service, etc.). The idea being that after it expires it comes up for renewal and there is an expected point in time for contact between a product's tech lead and TechCom to evaluate whether changes are needed and estimate resourcing. That could sometimes be almost nothing. Sometimes not. A way to make it part of [21:38:03] the cycle. [21:38:28] I didn't pursue it, but curious what people think. [21:39:12] Krinkle: ones that haven't been implemented yet? [21:39:15] Krinkle: it comes up for renewal if implementation hasn't started yet? or isn't complete yet? or always and forever? [21:39:26] KateChapman: implemented ones. [21:39:35] perhaps for each RfC we should also make it clear what kind of RfC is it: is it immediately implementable, is it a policy, it is something that will make us future-proof, etc? [21:40:07] e.g. "we approve implementation of service X in accordance with RFC T123; this expires in 2 years." [21:40:08] T123: Turn on "diffusion.allow-http-auth" - https://phabricator.wikimedia.org/T123 [21:40:14] RfC's that lack resources to actually do the ideas beinh the RfC are the real problem [21:40:44] Krinkle: yeah, this is something we've kind-of done with wikidata's service [21:41:03] good point, forgotten about that. [21:43:31] Krinkle: in the expiration scenario, what would happen if/when, say we approve an RfC for 2y, but it never gets anywhere? do we re-evaluate it? do we push for it? etc... [21:43:53] i think this would happen with most of the RfCs we currently have in the backlog btw [21:44:49] Yeah, we have some "approved" but not-yet-implemented RfCs from years ago which might be controversial if I suddenly turned up and started breaking the world to implement them, I think. [21:45:03] exactly [21:45:48] 15 minutes left [21:45:50] mobrovac: No, if the RFC is a technical implementation for a product need, it being implemented or not isn't really our issue. [21:45:56] any other questions or comments to talk about? [21:46:25] or shall we keep talking about improving the rfc process? [21:46:37] Maybe it wasn't clear - I was talking about expiry in the context of changing standards and policies. The idea being that, you've built something, 2 yeaers have passed, and to put it boldly, we want a way to help engineers justify doing refactoring to match other general policies passed through RFCs since then. [21:46:48] So I have a question here. Is there a clear boundary on what can be an RFC and what can not? a rule of thumb would help a lot [21:46:55] The expiry would be a way to bring it up, as part of a renewal, which, without, in theory would mandate sunsetting. [21:47:30] like I really like to change logo of mediawiki to something more modern, but is it correct to go through RFC. if not, then what is the right way? [21:47:33] Oh, right, expiry of mandate for production systems unless they re-certify against current TechCom standards? That'd be challenging. [21:48:09] Krinkle: that's an interesting idea and a valuable one (since it directly minimises tech debt), but the question is: how do we enforce that? [21:48:17] Amir1: I wonder if that is a product decision more than anything. I did note it in the Platform Evolution plans but we haven't revisited it yet. [21:48:27] Amir1: we say that RFCs are at least one of: strategic, cross-cutting, or hard to undo [21:48:50] mobrovac: well, I think it's in scope for the CTO to decide to enforce it. It's a matter of how we want it to work and whether it can scale appropriately. [21:48:55] KateChapman: TimStarling: Thanks I got my answer then [21:49:12] Amir1: pretty much any technical question can be an RFC - from a problem looking for solutions to a concrete solution seeking approval. However, to stay within skope, and to reduce overhead, it should already be clear that we actually want to do whatever the RFC proposes to achieve (a product level need/wish/commitment). [21:49:19] Krinkle: right, good point [21:49:24] And there should at least be a good chance of resourcing [21:49:45] James_F: I agree it'd be a tough sell. It's worth putting into words what the alternative is. If the alternative is, tech debt galore, can we conciously accept that? but, if we accept that maintenance isn't optional, then we shouldn't have anything to worry about. The renewal would just tell you what you already know. [21:50:29] Krinkle: FWIW, every company/org I've talked to does architectural compliance at the build/change phase rather than the run/maintain phase of a system lifecycle. [21:50:32] KateChapman: the MEdiaWiki logo... is that really a "product decision" in the same sense as other product decisions? I mean, the "consumers" of the "product" never see that logo. [21:50:41] Like the thing some countries do for car road-readiness (MOT in UK, APK in NL) [21:51:21] Amir1: That'd be a product and branding decision. Not in scope for TechCom or RFC. [21:51:21] duesen: The MW logo is shown to the consumer of the product MediaWiki, i.e., sysadmins installing it. [21:51:32] KateChapman: it's a product decision for the platform/software. it'S primarily developer-facing. it's not a technical decision, true. but the audience is pretty much the same [21:51:35] the MW logo is on the bottom of every wikipedia page [21:51:42] Krinkle: noted, sorry for disruption. Mostly it was an example [21:51:49] Where some products are owned in the Technology departmenet (e.g. MediaWiki core product manager is in Core Platform Team) - but not TechCom. [21:51:54] https://en.wikipedia.org/static/images/poweredby_mediawiki_88x31.png [21:52:29] James_F: yes, sure. and that *is* a product.- i'm just highlighting the fact that it's different from the "product" we usually mean, wich is essentialyl the UI of mediawiki. [21:52:39] but yes, it is for the MediaWiki developer community to decide on [21:53:05] the logo was changed once before, from a sunflower photo to a vector traced sunflower [21:53:09] controversal q: should it be in TC's scope to figure out who is responsible for things it deems not to have authority over? e.g. in the logo example, would people that come to TC expect TC to tell them "you have to go to X" rather than "nope, that's not us" ? [21:53:17] that discussion occurred mostly on wikitech-l and was reasonably inclusive [21:53:19] Totally. [21:53:31] and rfcs are the only formal decision making process whe have for the developer community. though it's not really in scope of techcom, i admit. [21:53:42] i'd probably file a ticket and start a discussion on wikitech-l [21:53:51] Amir1: I think the following links can be improved, but the current answer to your question of what needs TechCom involvement - is defined at https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Charter#Mission_Statement and https://www.mediawiki.org/wiki/Requests_for_comment/Process [21:54:04] and just change the logo on mediawiki.org to make people aware ;) [21:54:28] change the logo to a pink potato, whoever complains first gets to be the decision maker [21:54:40] As long as it's not a damn goat. [21:54:44] Krinkle: i think the question of what *needs* an rfc is quite different from the question of what *can* be an rfc. [21:54:57] James_F: ooooohhhhhhh! [21:55:14] James_F: well i think now it's just a matter of time before a goat appears on mw.org :P [21:55:22] Oh, gods, what have I wrought?! [21:55:27] what, did someone remove the goats? [21:55:35] lol [21:56:08] my thought on the logo is Cindy would be the right person to lead that decision in her Product Manager role on Core Platform [21:56:25] in the case of gerrit privilege policy the discussion was formally outside our scope, but we facilitated it anyway [21:56:27] https://pbs.twimg.com/profile_images/896400737843937280/3eusuAvC_400x400.jpg [21:56:59] KateChapman: Agreed. [21:57:09] duesen: I quite like your meta definition about "strategic, cross-cutting or hard to undo", I admire that we want to be more technical and specific. But it's vagueness seems actually useful to me. As you say, anything can be an RFC. If a small matter is topic of debate and becomes a blocker, it will become hard to undo and by extent strategic. [21:57:10] I think we can facilitate inclusive discussions of the MediaWiki technical community if there is a desire for us to do that [21:57:18] +1 [21:57:29] Krinkle: That sounded like https://meta.wikimedia.org/wiki/Cunningham%27s_Law [21:57:50] Amir1: Yes, very much so. [21:58:26] we are almost out of time btw, 2 minutes left [21:58:37] Thanks for the answers, it was extremely helpful [21:59:45] With the gerrit merge policy, basically +2'ers act as sensors to gauge consensus. If something seems problematic, they can eventually escalate to TechCom. However, not all TechCom tasks are RFCs. We have a committee workboard as well. It's only an RFC when the decision is something that requires wider input, which it doesn't always, though usually does. There's also a (small) room for interpretive inqueries (e.g. there is a policy about [21:59:45] this, but how is it meant to apply to X?) [22:00:19] we usually handle that on talk pages though [22:00:33] Thanks for asking these questions Amir1 ! [22:00:42] time's up! [22:00:48] thanks everyone! [22:00:57] #endmeeting [22:00:58] this was a good office hour, i think we'll do that again! [22:01:02] me too [22:01:06] Meeting ended Wed Apr 17 22:00:57 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:01:06] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2019/wikimedia-office.2019-04-17-21.05.html [22:01:06] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2019/wikimedia-office.2019-04-17-21.05.txt [22:01:06] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2019/wikimedia-office.2019-04-17-21.05.wiki [22:01:07] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2019/wikimedia-office.2019-04-17-21.05.log.html [22:01:23] * duesen needs to go to bed now [22:01:38] * mobrovac waves [22:01:47] * KateChapman needs to pet her goats and then take pictures of them to hide on mw.org :p [22:11:38] lol [22:12:05] KateChapman: i'll take photos of my goats when i get back home, we can have a competition! [22:12:33] mobrovac: nice we can have a goat off! [22:12:38] hahahahah