[21:00:03] #startmeeting TechCom RFC discussion [21:00:25] come on bot! [21:00:54] you had a leading space there [21:00:58] it might not like it [21:01:05] oh, teach me to cut and paste [21:01:09] The bot has been on wikibreak for a while. [21:01:15] #startmeeting TechCom RFC discussion [21:01:16] Meeting started Wed Aug 21 21:01:15 2019 UTC and is due to finish in 60 minutes. The chair is KateChapman. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:01:16] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:01:16] The meeting name has been set to 'techcom_rfc_discussion' [21:01:21] that did it! [21:01:21] \o/ [21:01:37] #topic RFC 2019 Process Amendments https://phabricator.wikimedia.org/T216308 [21:01:49] okay, who is here to discuss RFC process amendments? [21:01:56] * duesen wibbles [21:02:15] * KateChapman wobbles [21:03:25] * brion whee [21:03:52] 'ello [21:04:12] o/ [21:04:31] Just saw the email for this. I didn't know this discussion was happening. [21:04:34] okay, so let's get started and others can catch-up as we go [21:05:19] halfak: then I'm happy that I wrote that email :) [21:06:08] o/ [21:06:12] In the old times, this meeting was on my calendar [21:06:20] I'm here [21:06:21] Now it's kinda invisible [21:06:31] MaxSem would you like it on your calendar? [21:06:52] I think we had some trouble closing out stale RFCs when we went through the backlog, current process requires every closed RFC to go through last call [21:07:03] Yep, having it in the eng calendar would improve visibility, imho [21:07:06] Shoot. I need to run. Will catch up later. [21:07:17] should it be possible for the author to withdraw an RFC? [21:07:42] and what should we do for RFCs that were created by former employees? [21:09:22] TimStarling: The author should be able to withdraw an RFC, yes. [21:09:30] Also, we should be able to close or drop an RFC for lack of interest [21:09:32] can someone else then unwithdraw it? [21:09:57] I don't think the staff status as such should make a difference [21:10:04] yes, someone else could then unwithdraw it [21:10:27] I wonder if really then the RFC just needs a sponsor [21:10:28] whether the person is staff or volunteer, if they're gone and not coming back, they're not going to withdraw or push it forwards [21:10:31] but if it's clear that neither the author nor anyone else has an interest any more, we should be able to cose it, or drop it off the board, or put it into a hidden column [21:10:40] so if someone left as staff then someone else would need to pick it up for it to stick around [21:11:03] or the person in question would need to express an interest in persuing the rfc as a volunteer [21:11:06] not unheard of [21:11:28] the current process for untagging is not really reflected in the process document, it just says "If TechCom considers an RFC out of scope, it may close the task as invalid" [21:11:34] * duesen notes that yurik is still around - he's indeed in this channel right now [21:11:49] yep [21:11:56] * yurik reads up [21:11:57] heh :p [21:12:04] should it instead say that the RFC can be untagged by techcom resolution? [21:12:17] yurik: sorry i pinged you, you just served as an example. but feel free to join in ;) [21:12:19] regardless of whether it is actually in scope? [21:12:51] TimStarling: yes. and we shouldn't say "close". it's really "remove from the process". it may still be useful in other ways. [21:13:16] actually, it seems easier to find criteria for removing an rfc from the process than for closing the ticket [21:13:38] sorry, confused, is it in regards to any of my RFCs? Or a general discussion about RFC processing? [21:14:03] yurik: the discussion is regarding stale RFCs and what should be done about RFCs for which the author has departed [21:14:21] thanks @TimStarling , I guess since i am still around, doesn't apply [21:14:25] duesen used you as an example of a person who loves us too much and can't stay away [21:16:48] :P [21:18:29] So. I see three options for "remove from the process when stale": 1) close invalid or declined ("stalled" is not closed) 2) untag 3) put into a (hidden?) attic column [21:18:56] I feel #3 is the most clear in terms of process. [21:19:51] I do prefer a clear process over untagging (which seems like it loses information and can leave things 'in the void') [21:20:04] I'd say we can do this after a year without significant activity. I don't think we have to give notice, it'S easy enough to undo. we should just add a brief note explining what happened. [21:20:07] undecided between attic column vs closing [21:20:42] closing works for some tickets, but others are not "just" rfcs, and would need untangling. [21:20:52] also, close as what? nither declined nor invalid seem to fit [21:21:42] Yeah, right now for both resolution and declining we do it based on that. [21:21:55] So we have column primarily, and if it's purey an RFC task we also close the task [21:21:55] declined sounds appropriate-ish, but agreed on untangling being an issue [21:22:52] so, what shall the new column be called? stale? stalled? attic?.. [21:23:48] I'll vote for stalled [21:24:00] i'd go with 'stalled', though 'attic' is picturesque metaphor :) [21:24:36] We'll want to distinguish it clearly from backlog which is also "stalled" (that is, it is blocked on one more more requirements being put forward). [21:24:42] we should be clear on the fact that we do not intent to revisit things in that column [21:24:54] if someone else revises them, fine. but they are out of the process. [21:24:57] Would we document the distinction as only being that techcom members decided to move it? [21:25:30] hmm, well that's a difference from how i'd think of 'stalled' perhaps then [21:26:05] Well, in one case the idea is that we are waiting for someone else to do something. In the other case, we have given up hope that anyone will do something. [21:27:28] The two are similar, but making the distinction to pay more attention to the rfcs that we haven't given up on [21:28:24] Are we ready to move on to another proposal? I see a need for another column. Or for renaming the inbox. [21:29:33] The idea is to provide a clear way for an rfc author to say "this has seen discussion and improvements, please have a look now, and see if this can move to last call / irc meetng / under discussion" [21:29:53] currently, youÄd do that by mocing the ticket to the inbox. but that's not documented, and not very intuitive [21:32:05] we have board grooming rotation to guide authors through that [21:32:51] not sure that works. board grooming picks up tickets that are seeing activity [21:33:01] often, a ticket becomes ready for review when activity has dieed down [21:33:07] authors have no guidance in that situation [21:33:59] Yeah, I think our activity triaging should cover that. The only required column moves that don't depend on us are 1) request irc meeting, and 2) from backlog to inbox after fulfilling requirements. Both of which are documented. Requesting IRC meeting is self-explanatory, and moving to inbox is something we can include in our boilerplate comment in which we eplain missing requirements. [21:34:17] Can't think of a better name, but maybe others do. [21:34:34] if the author writes "techcom please move this forward" in a comment, then the person on board grooming duty will see that and do something with it [21:35:20] yeah, we don't depend on authors or participants moving things to inbox for us to notice. It's allowed, but by no means neccecary. [21:35:54] maybe there is a need for a column for RFCs that are blocked on techcom, that would be the kanban way to do it [21:36:47] that's kind of what the inbox is. not sure we need a different column, maybe just a better name "needs TechCom attention" or something. [21:37:10] And some documentation on how to make an rfc go from "under discussion" to last call. [21:37:41] btw, why do we have a column for requesting irc meetings, but non for requesting last call? [21:37:50] maybe just "TechCom inbox" instead of "inbox" [21:37:59] that way it is clear whose inbox it is [21:38:10] hmhm [21:41:17] *** btw 20 minutes left *** [21:42:37] How about the requirement to have RFCs on phab? Details can be somewhere else, but the essential proposal should be on the ticket. [21:42:43] should we make this a requirementß [21:43:59] I think that really helps make the discussio more readable to have it in one place [21:45:04] yeah agreed. With some of the older ones it is hard to figure out what is going on [21:45:19] the RFC process started before phabricator existed [21:45:30] it was originally wiki-only [21:46:22] when phabricator was created, someone went through all the RFCs open at that time and made tickets just linking to the wiki, with no further details [21:46:49] does that bring up the question if nobody really is stewarding them and they are just linked to on wiki are they stalled and should be noted as such? [21:47:13] *nod* [21:47:16] probably [21:47:30] +1 [21:48:45] which may mean it's somebody's homework to mark them ;) [21:49:11] * KateChapman ducks :p [21:49:49] well we can parcel that out later ;) [21:50:26] Krinkle: any other ideas you want to float in the last ten minutes? [21:50:47] *** 10 minutes left *** [21:51:40] may as well wrap things up, we seem to be petering out [21:53:09] Yeah, sorry, I think we've covered the ones we were unsure of, and looks like there isn't new input we'll get today. [21:55:11] okay, I'm happy to close things if nobody has any additional comments or questions [21:55:47] or just sit here in awkward text silence for 5 minutes :p [21:55:55] * duesen is dozing off [21:57:00] * Krinkle has a post-Wikimania jetlag [21:57:05] conference lag* [21:57:10] * TimStarling has the flu [21:57:17] * KateChapman just woke up too early [21:57:20] just put in a sick leave request, going to go back to bed [21:57:34] :( ohno [21:58:14] feel better [22:00:38] #endmeeting [22:00:38] Meeting ended Wed Aug 21 22:00:38 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:00:38] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2019/wikimedia-office.2019-08-21-21.01.html [22:00:38] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2019/wikimedia-office.2019-08-21-21.01.txt [22:00:38] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2019/wikimedia-office.2019-08-21-21.01.wiki [22:00:38] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2019/wikimedia-office.2019-08-21-21.01.log.html