Hello,
On 27 February 2016 at 01:00, Rob Lanphier robla@wikimedia.org wrote:
Hi folks,
An ArchCom RFC triage (per https://phabricator.wikimedia.org/T125865) was penciled in for this past RFC meeting (https://phabricator.wikimedia.org/E144), but I was out for jury duty and wasn't able to make the push for this or facilitate it if we stuck with my hasty plan. I'm done now, and would be happy to accommodate assuming everyone is available and up for helping out with a triage for this coming meeting on Wednesday 2016-03-02 (https://phabricator.wikimedia.org/E146)
Triaging is a great idea, Rob! I know this is only the beginning of this new "modus operandi" for both the ArchCom and RfC's, but I'd suggest to make triaging an integral part of each ArchCom meeting (I'm guessing that it wouldn't take more than 5 minutes given the weekly meeting schedule) in order to avoid falling behind.
The point of the triage would be to try to ensure that more RFCs have assigned shepherds on ArchCom. That, in turn, would hopefully make it more likely for an RFC to make it through the process more quickly. Instead of having to ask all of ArchCom status about a particular RFC, there would be a single ArchCom owner to check in with.
+1! This should greatly simplify the workflow not only for RfC authors, but interested parties as well.
Any RFC that doesn't have a shepherd is not likely to move through the process. There are always going to be several RFCs that don't have shepherds. Just submitting an RFC doesn't guarantee that an ArchCom member will think your RFC is important. Life is hard that way. Make your case!
Sometimes the inability of the ArchCom to assign a shepherd might be due to the unclear "category" the RfC belongs to: is it WM-centric or MW-centric, does it encompass only FE changes or BE changes as well, compatibility with previous solutions, etc. So perhaps RfC authors could be encouraged to attach certain (predefined?) labels to their documents to make the triage easier?
Note also: shepherd != slave. Even when an RFC has a shepherd, there's no guarantee that the RFC is a high priority for the shepherd. Certainly, the shepherd's credibility as a worthy ArchCom member is potentially damaged by foot dragging, but don't bank on being able to dump blame on the shepherd if your RFC isn't going fast enough for your taste.
I may be off here, but my understanding of the shepherd's role is to work *together* with the RfC author in order to secure the necessary buy-in from various parties. In that sense, I think it's important to make it clear to the respective authors that should progress be stalled, they're supposed to "share the blame" with the shepherd :)
Thoughts?
Not a thought, but more of a question. Would it make sense to limit the number of RfC's an ArchCom member may be the shepherd of? After all, ArchCom members do have other obligations, so having a large backlog per person might send the wrong signal that things are moving along when they are in fact not.
Cheers, Marko
Rob
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l