Page MenuHomePhabricator

RFC Process: 2019 amendments
Open, NormalPublic

Description

Preamble

The 2017 revision to the RFC process simplified things enormously. I believe this has been good for the start of an RFC. The barrier to entry is low, and there's no unnecessary formalities or bureaucracy.

But, I also believe it's made it harder for RFC authors and stakeholders to anticipate what's going to happen when and how.

Let's take what we've learned since 2017, about processing RFCs, and incorporate it into the process.

Objective and scope

  1. Document what aspects an RFC should have in order to be considered ready for wider discussion (e.g. moved from being a draft in "Backlog", to "Under discussion").

Documenting these aspects will enable authors to get further into the process without being blocked on "discovering" these aspects, e.g. through helpful participants asking the questions, by TechCom, or by the author analysing past RFCs. This will give authors more autonomy, and should allow for the process to be quicker overall.

  1. Document what sub-processes we believe are needed for most RFCs before we allow ourselves to believe a proposed solution can be considered approvable.

The purpose of point 2 is to allow RFC authors and stakeholders to better anticipate what will happen. I believe that currently, it is generally unclear to participants whether an RFC could be put on last call if TechCom reaches consensus, or whether they plan to involve others or ask certain questions still before proceeding to that step.

Scope:

  • Not a complete overhaul.
  • No new requirements for RFC authors.
  • We'll add "should" and "recommended" statements that RFC authors may follow.
  • We may add new requirements for TechCom members to follow.

Problem statements

  1. There are questions that participants (esp. TechCom members) ask on almost every RFC. This shouldn't be the case.
  2. There are certain sub process that participants expect from most RFCs. We should make it hard to forget about these.
  3. There may be mistakes we've made. If we can amend the process in a small way to prevent these, we should consider doing so.

We should pick of few of these and document them as recommendations. I also think we should keep the process flexible so that it can scale to all sorts of small and big ideas, and thus no mandatory fields (I think?). But for the common case, we can probably come up with a default format to recommend.

Proposal 1

  • ...

Event Timeline

Krinkle created this task.Feb 16 2019, 4:15 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 16 2019, 4:15 AM

Here's a random idea:

  • Allow no more than 2 concurrent RFCs on last call. And, no more than 1 last call ending in the same week.

Reason being to make sure everyone can have the time, focus, and opportunity they need.

daniel added a subscriber: daniel.Feb 19 2019, 1:42 PM

There is also the change that Marko proposed: require the RFC to be on phabricator, with the option to reference wiki pages; and require teh RFC discussion to be on phabricator, and discourage on-wiki discussion once discussion on phab has started.

Here are a few ideas I have:

  • provide a checklist for "when should I file an RFC"
  • provide a checklist for "what should be in an RFC document"
  • consider a last call with no feedback from outside TechCom failed. Positive feedback would be required for an RFC to be approved. This ensures that we solicit input from relevant stakeholders.
  • make explicit that it is TechCom's job to solicit input from relevant stakeholders. Presently, we usually just hope that relevant people would read the radar email and react.
Tgr added a subscriber: Tgr.Feb 21 2019, 4:01 AM

It would nice if there was cleaner differentiation between RfCs blocked on lack of consensus, lack of interest, lack of resources to implement, or lack of time for discussion (as in, waiting for an IRC discussion to be scheduled, which can sometimes take a while).

kchapman assigned this task to Krinkle.Mar 6 2019, 9:35 PM
Krinkle moved this task from Inbox to In progress on the TechCom board.Mar 6 2019, 9:37 PM
Krinkle moved this task from Inbox to Under discussion on the TechCom-RFC board.
Krinkle triaged this task as Normal priority.Mar 13 2019, 1:31 PM

Note to self:

In the future we may have a few boilerplate questions for the RFC author to answer on Phabricator before scheduling a requested IRC meeting. Once we've tried this out and refined it a bit, we can also document those publicly on the RFC process page for better discovery.

Depending on when that happens, it can either ride this amendment or be part of a later revision.

Another note based on a comment from @Milimetric in today's TC meeting.

Our process doesn't have clear path for how to close stalled RFCs. We are currently encouraging RFCs to be started very early on, before there is known resourcing or product support. The process currently states that TechCom can move these to the backlog where they reside until resourcing, product support and a problem statement exist.

The only paths to closing are:

  • Upon triage, when the RFC is out of scope (per TechCom's charter).
  • Via Last Call, if TechCom declines the problem statement and/or technical proposal (once either exists).
  • By the author if they withdraw the RFC.

This means feature ideas for which an RFC was started early on by an individual that doesn't own the affected product, remain open indefinitely in the backlog. See T91137 for an example.

Do we want to allow for closing an RFC in this stage? If so, on what grounds? And what about RFCs in this stage that are not old, do we still want to encourage use of the workboard for new product proposals in an early stage? (I'd say, yes, that's still desirable and useful to get involved early on).

Tgr added a comment.Apr 17 2019, 9:21 PM

Do we want to allow for closing an RFC in this stage?

Does not seem any different to me from closing tasks on the grounds that team X does not intend to work on it anytime soon... which has not been popular. Is there any practical benefit from closing them? You can hide workboard columns, replace the project tag etc.

Krinkle added a comment.EditedApr 17 2019, 11:02 PM

@Tgr In your example "closing an RFC" is not the same as "closing a task tagged TechCom-RFC". If the task represents only an RFC, then closing it would mean closing the task, there is no reason not to. If the task in question tracks other work, or tracks a general intent for a product or feature, then "closing the RFC" would mean removing the tag (or moving to a certain column). In both cases, it can always be re-tagged or re-opened.

The question is, whether we want to allow for this at all, to "closing the RFC process" for an RFC in the backlog that did needs product approval but has no recent participation from a relevant product owner.

The added value of doing so would be to reduce workload of triaging the backlog for us. As well as for all other participants to have a clear view of what is happening and where they can participate and contribute.

Maybe we should just have an "attic" column.

Maybe we should just have an "attic" column.

+1. Or a "no resources" one :P

+1, I like "No Resources"

Krinkle removed Krinkle as the assignee of this task.Jun 10 2019, 8:29 PM

The process should ensure that at least one TechCom member spends some time digging into the RFC before it goes to an IRC discussion or a Last Call. In the past, some of us usually did that at some point, but we don't presently have any mechanism to ensure this. I think we should.

Krinkle updated the task description. (Show Details)Aug 2 2019, 5:56 PM

TechCom is hosting a IRC meeting on this: 21 August at 2pm Pacific/23:00 CEST/21:00 UTC in #wikimedia-office

tagging so I know to leave a comment per discussion with @kchapman

Random thoughts about my experiences with the RFC process:

  • People showing up for the RfC meeting were wholly unprepared and wasted a LOT of the very short time slot asking basic comprehension questions that should have been addressed on the talk page before the meeting
  • Speaking of the meeting, 1 hour is seriously not enough time to have a cogent discussion about something as big as an RfC
  • The process to get an RfC through the track is very poorly defined. Ask 3 different people what you need to do in order to move the RfC to the next stage and you'll get 4 different answers
  • Forcing the RfC to live in a bajillion different places makes communication difficult. Why do we need to have discussion on phab but content on mw.org? Let's just use phab as a placeholder with a link to the real content, so that phab stuff can happen with that task, but all discussion lives on mw.org between the RfC page and the talk page
  • Ocotillos are pretty and huggable
  • Communicate with the stakeholders (aka include the RfC authors in this) BEFORE scheduling the IRC meeting, to ensure that a time is chosen that works for everyone. It's frustrating when IRC meetings are scheduled for things that I'm involved in at times that I'm literally unable to attend
  • I see above that you want to move all the discussion to phab instead. That is a massive mistake. Barrier to entry on phab is higher (not easy to create an account and contribute compared to on-wiki), and it's impossible to have multiple independent discussions on phab whereas it's super easy to have threaded discussions on mw.o
Isarra added a subscriber: Isarra.Aug 30 2019, 12:59 AM

Based on my experience with two RfCs this year, two things stood out:

  1. People don't actually read the RfCs before discussing them. Depending on the level of their involvement in the discussion, this wouldn't necessarily be an issue, except:
    1. This is apparently the expected norm for the IRC meetings.
    2. Some parts of MediaWiki, nobody (at the WMF) is really familiar with it to begin with, and you can't have a meaningful discussion about something nobody understands, has read into, or knows what's actually being proposed. We explained, in detail, the use cases. We linked to dozens of examples of demand for the functionality. We included sample code and examples of usage, and described the limitations with the current software. We were then, in the meeting, asked questions we had already answered, in detail, in the RfC itself, and not realising the people asking perhaps hadn't actually read it to begin with, stumbled to try to come up with better, clearer explanations on the assumption that they had and it what was there wasn't good enough. Much of what was discussed, the questions and recommendations, simply made no sense in the context of what we were trying to resolve or proposing, and it was incredibly frustrating trying to get the discussion back on topic. In the end, we were suggested to do something that was not only not feasible as far as we could tell having looked into it and worked on and maintained the relevant software for years, but whose very infeasibility had basically been the entire premise of what the RfC was seeking to resolve from a technical standpoint.
    3. After a point, it's just downright disrespectful.
  2. A double standard between how WMF- and third-party-written RfCs are handled and move forward:
    1. WMF written RfCs, if nobody shows up to object, they move forward.
    2. Third-party written RfCs, if nobody comes out to supports it, no matter how much we've tried to reach out to potentially relevant parties, it's not good enough and requires more feedback in order to move forward. Even when it turns out the main reason we haven't gotten any meaningful feedback is because we're the ones most familiar with this part of MediaWiki and its ramifications to begin with. Bonus points when there are a few other people within the WMF who probably could meaningfully comment, but they don't want to get involved after someone from another team left some objections that as far as we can tell aren't even based on the proposal or sample code to begin with (and this person hasn't come back to explain any of it, either, despite being asked multiple times).

Basically the whole thing comes across incredibly WMF-centric, and it doesn't feel like there's any room left for actual... requesting comments. As a volunteer and third-party developer, I'm not even sure I see the point trying at all anymore, as things stand.

RhinosF1 moved this task from Incoming to Done on the User-RhinosF1 board.Sep 1 2019, 8:44 PM

Some thoughts said to @kchapman during the meeting over PM

22:21:31 <RhinosF1> TechCom should be able to un-tag RfCs no-ones interested in etc. and/or decline the task.
22:22:08 <RhinosF1> and when things are stalled then there should be options to untag/decline or call attention to it
22:43:53 <RhinosF1> yes, RfCs should be all in one place :)
22:44:56 <RhinosF1> as brion said makes it easier to read and for everyone to find stuff and work out what's going on