[17:50:29] TechCom is hosting an office hour on the new and improved RFC process here today at 21:00 UTC (2pm PDT, 23:00 CEST) [19:55:22] duesen: cool :) is there a plan to have another one at an earlier time? [19:56:47] kostajh: at some point, yes :) We have a slot reserved in the CEST-afternoon of the first wednesday of each month. But we don't always use it for public discussions. [19:56:59] Also, attendence of that slot has been weak... [19:57:40] kostajh: while i think we'll have a europe-friendly office hour soon, it will probably not be specifically about the new rfc process. but since it's an office hour, any topic is welcome :) [20:15:04] cool [21:01:41] #startmeeting TechCom office hour [21:01:41] Meeting started Wed Apr 8 21:01:41 2020 UTC and is due to finish in 60 minutes. The chair is duesen. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:01:41] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:01:41] The meeting name has been set to 'techcom_office_hour' [21:02:01] #topic new RFC process, and whatever else folks want to talk about [21:02:13] #link https://www.mediawiki.org/wiki/Requests_for_comment/Process [21:02:43] o/ [21:03:01] Hey Krinkle! [21:03:07] So, who else is here for the office hour? [21:03:22] o/ (for a little bit before I crash) [21:03:57] * James_F waves [21:04:27] Hey James_F! So it'S not just techcom on its own, that'S good :) [21:06:25] * duesen wonders whether he announced the correct time [21:06:40] I think you did. [21:06:50] I'm lurking but have not read the RFC process document [21:06:53] Maybe people are just happy with the plans? [21:06:56] Or that. :-) [21:07:18] Or they don't care ;) [21:07:33] James_F: are you happy with the plans? [21:08:09] those imagining crickets and tumbles rolling in the quiet western background setting, might be interested in learning about the real-world problems that tumbles are causing. – https://www.cgpgrey.com/blog/the-trouble-with-tumbles [21:08:23] I for one was amazed :D [21:08:53] I'm also here to hear about it. I'm actually curious about them, but I'm here by luck, mostly because my baby daughter doesn't like the idea of sleeping in the night. And since I cannot sleep as a consequence I decided to drop by. [21:09:24] aharoni: as good a reason as any! [21:09:37] duesen: Yes. My main issue is with things that need product ownership and don't have them for whatever reason. The TechCom RfC process has been working well from my POV. [21:09:38] Krinkle: do you want to give a quick summary, while i read up on tumbleweed? [21:10:31] Maybe this is addressed in the document that I didn't really read, but as there's not much conversation yet, I'll ask something that came up in CPT process discussions: [21:10:35] From Phase 2: “Software engineer(s) for the initial implementation. (One or more persons, and/or associated teams)”. What level of commitment is this? Given that non-negligible may elapse between this phase and approval, people’s availability might change. [21:11:53] bpirkle: A rough "Yes I/we plan to do this" generally suffices. [21:12:09] It was added to avoid situations where everybody assumes someone would do it when really they were just interested in seeing it happen. [21:12:39] Which has in the past led to a lot of wasted time and effort into fine-tuning something that has no implemetnation intended. [21:13:20] Beyond that, yeah, we're not yet worried about the situation where that promise may fall short or if situations change. Which I acknowledge could be abused, but alas, this is the first step in the right direction. Possibly enough. [21:13:42] Ok, thanks. So more of a "I'm willing and interested, assuming things work out" and not a "My time has been approved and I have high confidence that I can actually participate"? [21:14:09] bpirkle: for staff endavours, a team name suffices there. We're not worried about who would do it. I might need to clarify the phrasing there. But inviduals would only be listed if it's something you'd resource personally and not on behalf of the team. [21:14:46] Makes sense. [21:15:00] I phrased it this way to make sure it doesn't feel alien to volunteers who obv don't have a wmf team. [21:15:17] Basically, what we want to make clear is that an RFC is not a way to get resourcing. That'S a pretty common misconception, especially for rfcs comming from outside the org. [21:15:48] Might it be worthwhile having a "supporters" set of people who are willing to cheer it on/help out a bit but don't want to be the main owners? [21:15:49] Yeah, it also helps catch early on if someone creates an RFC when their intent is "I'd like WMF to create this feature" [21:16:03] as opposed to "Guide me build this" [21:16:16] Right. [21:17:54] Which is fine either way, but we've more or less decided not to encourage people (incll TechCom) to actively participate on an RFC until we know at least that there is intent to build it from someone somewhere. And if not, we can focus on that instead, e.g. by putting the volunteer in touch with the relevant product team, or other volunteers who might help build it. [21:20:57] So, this has been three minutes of awkward silence... [21:21:15] If nobody has any other questions of topics to discuss, i'll call it beer-o-clock ;) [21:21:27] I do [21:22:13] \o/ [21:22:40] The discussion above makes sense for features that can be built by volunteers or by teams other than core platform. But what happens with RFCs whether the implementation will have to heavily involve Core Platform? [21:23:16] s/whether/where/ [21:23:39] Why would things be different when implementation involves coer platform? [21:24:50] "intent to build it from someone somewhere", as Krinkle says, as opposed to "I'd like WMF to create this feature" [21:24:51] aharoni: such thing are essentially a feature request. the RFC process is mainly about the technical challenges of building someting, not to approve whether a feature will be on the roadmap. I'm not aware of a standard way to propose new products/features/extensions etc other than a phab task somewhere. These have often been done as RFCs in the past, and often not been very positive experiences as such. [21:26:00] For now, when that happens, this is something that would need to be decided on in Phase 2 around resourcing and stewardship/ownership. There you'd be working with whomever the lead vollunteer or product owner is to decide whether this is something they agree belongs to the product, and if/when they have capacity to help build and/or start maintaining it for you. [21:27:05] So feature requests can still use the RFC process, but it'd be stalled very quickly in Phase 2 because we can't decide what products will or won't get built. [21:27:36] OK, just to be sure—where's the link list of Phases? Perhaps I'm looking at the wrong link. [21:27:53] but if you're not sure where else to go, I think we're still fine having that in the process and try to do our best to get you in contact with whomever can help. [21:27:58] https://www.mediawiki.org/wiki/Requests_for_comment/Process [21:28:21] right... an rfc is not a way for getting things on a team's roadmap. the fact that there really is no way to do this at all other than informally talking to the right person at the right time over a cool beverage has been frustrating to me as well. [21:28:23] ah, right, thanks [21:28:59] Krinkle: btw, the fact that we don't have the process on the main RFC page is confusing. Can we just combine the two pages? [21:30:10] #action Krinkle: [not having] the process on the main RFC page is confusing. Can we just combine the two pages? [21:30:14] Yeah, will do :) [21:30:21] cool :) [21:30:23] (is that the right hash tag?) [21:31:14] i believe so [21:34:59] it's wewwy quiet... shall we close the meeting? [21:35:07] still here, still here [21:35:14] I was just reading the phases ver carefully [21:35:41] Phase 2 says: "If you're unsure about who the code steward or product owner is for a project, ask for help on the task" [21:36:37] This sentence comes a bit out of nowhere. What exactly is the product owner's role in this phase? [21:38:53] to say the request is part of their roadmap and they'll act as the code steward for it. [21:39:20] aharoni: if you are e.g. proposing to add a "share" link to every section of a page, and are looking for approval for the technical solution to do that, you also need someone to agree that this is actually something we want in mediawiki. [21:39:27] (see T18691) [21:39:28] T18691: RFC: Section header "share" link - https://phabricator.wikimedia.org/T18691 [21:39:32] which for the common case of a team building something and opening an RFC you'd just enter yourself (does not need to be the product mgt talking on-task directly). [21:41:09] Yea, but sometimes the effect is less "localized", and buy-in is needed from multiple "owners". [21:41:21] yeah, that's the tricky question—who has to agree :) [21:41:21] (e.g. adopting vue.js) [21:42:10] And the reason I brought up the core platform team specifically earlier is that the membership of the Tech com has a bit of an overlap with the Core Platform team :) [21:43:22] true. but oddly enough, we don't have that much influence on what the priorities of that team are. [21:44:23] aharoni: in phase 2 product ownership is mainly about maintenance after implemetnation, it is not about everyone it will affect and may have concerns. [21:45:01] In terms of concerns and who else "owns" part of the problem/solution, we refer to those as stakeholders. [21:45:12] and that can and shoudl indeed be a wide spectrum of teams and often is. [21:45:51] That is a bit strange though. In theory, the RFC is only abnout feasibility. In reality, we also want to check that there is also consensus on the desirability. [21:46:31] Yeah, right after P2 is P3 where stakeholders would voice those kinds of concerns. [21:47:16] like if someone says browsers are too incapable and we should compile Chromium into javascript and render client-side instead. performance might have a blocking concern about load time that will effectively block/decline the proposal. [21:48:16] ... in which case I'd suggest rescoping the problem so that we can explore another path forward instead. [21:48:47] we could compile php into wasm and just run everything on the client :P [21:50:13] note that the above is not -entirely- a joke. cf. https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/ [21:50:44] thanks, that's all I have [21:50:52] thanks for asking , these are good questions :) [21:51:34] (no beer for me, it's not smart to drink while in country-wide quarantine with small children) [21:51:48] good night :) [22:18:47] duesen: action item {{done}} [22:19:04] #endmeeting [22:19:04] Meeting ended Wed Apr 8 22:19:04 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:19:04] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2020/wikimedia-office.2020-04-08-21.01.html [22:19:04] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2020/wikimedia-office.2020-04-08-21.01.txt [22:19:04] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2020/wikimedia-office.2020-04-08-21.01.wiki [22:19:05] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2020/wikimedia-office.2020-04-08-21.01.log.html [22:19:35] Ha, thanks. Went into the kitchen and forgot to close the meeting