Hello,
On 27 February 2016 at 01:00, Rob Lanphier <robla(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Marko Obrovac, PhD
Senior Services Engineer
Wikimedia Foundation