Page MenuHomePhabricator

Assign RFCs to ArchCom shepherds
Closed, ResolvedPublic

Description

As of right now, #ArchCom-RFCs are frequently be assigned to person writing the RFC. As we try out the Rust
model (per T123606), and as we try to increase the speed by which RFCs move though the process, we intend to assign RFCs to shepherds on the ArchCom.

T123606 describes the shepherd role:

  • Makes sure that stakeholders are informed.
  • Guides the discussion.
  • Once the discussion plateaus or stalls & in coordination with the RFC author(s), announces and widely publicizes a "Final Comment Period", which is one week.

What this means from a practical perspective is that the shepherd is responsible for ensuring that an RFC is in the proper column on the TechCom workboard, and is responsible for nominating that RFC to be highlighted in an RFC meeting if/when the time is appropriate. Non-ArchCom members who file RFCs will have an assigned liaison who can keep them apprised of the status of their RFC.

See also my wikitech-l mail: "Using assignees for RFC shepherd"

Related Objects

Event Timeline

RobLa-WMF updated the task description. (Show Details)
RobLa-WMF raised the priority of this task from to Normal.

I've taken the liberty of assigning @daniel as the shepherd for T124752: [RFC] Expiring watch list entries

Possible shepherds that TechCom discussed on 2016-02-03
@Krinkle: T18691 RFC: Section headings should have a clickable anchor
@daniel: T88596 Improving extension management
@tstarling: T468 RfC: CentralNotice backend improvements

I also volunteered to look after T120164 (leaving aside my "shepherd" qualifications)

Due to the limited availability last week, we didn't get choices from @GWicke, @brion, and @Catrope. T66214 seems like a possible choice for @GWicke (albeit he's the author). What should we do here?

Due to the limited availability last week, we didn't get choices from @GWicke, @brion, and @Catrope.

From my perspective, "limited availability" is a recurring issue with some members of the Architecture Committee. This should be addressed.

T66214 seems like a possible choice for @GWicke (albeit he's the author). What should we do here?

I'm inclined to think that having the RFC author also be the shepherd is unhealthy and should be avoided. Ideally someone without a vested interest in the outcome would be advocating for a solution to the general underlying problem, instead of having a situation in which an author makes a specific implementation proposal and then pushes for that.

I'm inclined to think that having the RFC author also be the shepherd is unhealthy and should be avoided.

I'm conflicted on this. It really depends on what authority a shepherd has. If it is truly just advovacy role then the author is clearly is already motivated to be the advocate (they in fact might selfishly want to not be the shepherd so as to have someone else assigned the task of advocating for them). If the shepherd gets full delegation to make authoritative decisions, then I think you're right.

Do you see anything in the current proposal that gives the shepherd too much authority?

Thanks for this important discussion. I'm curious how these ArchCom roles might change and develop say 5 years out, and what already exists in terms of parallel roles at other IT organizations (e.g. Google). For example, might these roles 5 or 10 years ahead become project manager and associate project manager (who then might become a project manager a year later), while retaining their facilitator / shepherd relationship and foci, and in terms of who reports to whom organizationally especially? Thanks.

Here's my crude attempt to organize the "in discussion" column on TechCom-RFC board:

Assigned to ArchCom Members

@daniel
T124752: [RFC] Expiring watch list entries
T124792: RFC: Service Locator for MediaWiki core
T88596: Improving extension management
T113034: RFC: Overhaul Interwiki map, unify with Sites and WikiMap

@tstarling
T89331: Replace HTML4 Tidy in MW parser with an equivalent HTML5 based tool

@Krinkle
T18691: RFC: Section headings should have a clickable anchor

@GWicke
T105845: RFC: Page components / content widgets
T105766: RFC: Dependency graph storage; sketch: adjacency list in DB
T102476: RFC: Requirements for change propagation
T114803: Service-Oriented Architecture, quo vadis?

@brion
T118517: [RFC] Use <figure> for media

Assigned outside of ArchCom

@Ottomata
T114443: EventBus MVP

@Lydia_Pintscher
T124339: Track the #RfC backlog

@Qgil
T119030: WikiDev 16 working area: Collaboration

@RobLa-WMF
T123753: Establish retrospective reports for #security and #performance incidents
T120164: RfC: Institute "last call" period for MediaWiki RfCs

@cscott
T90914: Provide semantic wiki-configurable styles for media display

Unassigned

T91162: RFC: Shadow namespaces
T111588: RFC: API-driven web front-end
T114421: [RFC] Optional Travis integration for Jenkins
T114445: [RFC] Balanced templates
T114444: [RFC] Introduce notion of DOM scopes in wikitext
T30085: RFC: Allow user login with email address in addition to username
T114457: [RFC] Use `npm install mediawiki-express` as basis for all-in-one install of MediaWiki+services
T120380: RFC: Allow JSON values to be included in the API results
T114454: [RFC] Visual Templates: Authoring templates with Visual Editor
T119908: [RfC]: Migrate code review / management from Gerrit to Phabricator
T114251: [RFC] Magic Infobox implementation
T124504: Transition WikiDev '16 working areas into working groups
T120414: RFC: MediaWiki should provide a pluggable registry for editor interfaces

At the 2016-02-10 ArchCom meeting, we experimented with working this into the meeting. Here's what we discussed for each member:

As of yet, these aren't the top priority for each member (conversation was brief and didn't focus on that). I hope to better prepare for future conversations on this front.

We plan to discuss this in E144: RFC Meeting: Standardise on how to access/register JavaScript interfaces (2016-02-24, #wikimedia-office). In particular

  • Discuss what being a "shepherd" means
  • Answer the following:
    • Has this been working?
    • Is this the right thing to do?
  • Figure out of we have the right shepherd assignments for the ArchCom members.

My understanding from the notes from last week:

@GWicke - T124365 REST API versioning
@brion: T118517 [<figure> usage], maybe T120414 [editor plugin registry]?
@Catrope - T108655: Standardise on how to access/register JavaScript interfaces
@Krinkle: T18691 RFC: Section headings should have a clickable anchor (he will bring it up in FE Stds)
@daniel: T88596 Improving extension management (@Legoktm hasn’t been available)
@tstarling: T114445 Balanced templates

Also note, I probably won't be available for this week's IRC meeting (E144). I don't believe ArchCom planned to discuss assignments generally in the IRC meeting (so please disregard what I said in T125865#2025768)

Thanks everyone who participated in E146, our IRC meeting earlier today! This seems to be the bulk of what we covered (all times PST):

T126605: Create Wikimedia equivalent of Rust's Moderation subteam.Via Web · Wed, Mar 2, 2:07 PM
T12331: Introduce article creation log.Via Web · Wed, Mar 2, 2:10 PM
T111588: [RFC] API-driven web front-end.Via Web · Wed, Mar 2, 2:21 PM
T114421: [RFC] Optional Travis integration for Jenkins.Via Web · Wed, Mar 2, 2:26 PM
T114445: [RFC] Balanced templates.Via Web · Wed, Mar 2, 2:28 PM
T114444: [RFC] Introduce notion of DOM scopes in wikitext.Via Web · Wed, Mar 2, 2:32 PM
T120414: RFC: MediaWiki should provide a pluggable registry for editor interfaces.Via Web · Wed, Mar 2, 2:40 PM
T120380: RFC: Allow JSON values to be included in the API results .Via Web · Wed, Mar 2, 2:45 PM
T114454: [RFC] Visual Templates: Authoring templates with Visual Editor.Via Web · Wed, Mar 2, 2:49 PM
T119908: [RfC]: Migrate code review / management to Phabricator from Gerrit.Via Web · Wed, Mar 2, 2:52 PM
T114251: [RFC] Magic Infobox implementation.

I failed to explicitly make time for this in this week's ArchCom meeting, but @GWicke and I spoke about it after the meeting. He and I want to make the "around the table" checkin on each ArchCom member's assignments a standard part of the meeting. We haven't yet figured out how we want the reporting out from that meeting to occur, other than as a normal part of the meeting summaries (see mw:ArchComMinutes).

Status update from the ArchCom meeting today:

New RFCs:

T129435 RFC: drop support for running without mbstring (Gabriel): New, very focused RFC by Max, discussion started.

Upcoming IRC sessions:

T124792 Service Locator for MediaWiki core (Daniel): Introduce a service locator (aka DI container) to allow code in mediaWiki core to make use of the Dependency Injection (DI) and Service Locator (SL) patterns.

Under discussion:

T108655 Standardise on how to access/register JavaScript interfaces (Roan): Considering to split out contentious part (file-based require, or something like it; to support embedding libraries), move forward on less controversial part (basic module-name-based require infrastructure)

T18691 RFC: Section headings should have a clickable anchor (Timo): Reworking proposal with designers & Volker

T124504 Transition WikiDev '16 working areas into working groups (RobLa) Finding folks to fully assume ownership on following up from each session has been difficult

T128351 RfC: Notifications in core (Brion): Discussed last week, now clarifying interfaces & scope.

T66214 Use content hash based image / thumb URLs & define an official thumb API (Brion): Discussion last & this week.

T118517 [RFC] Use <figure> for media (Brion): Revisit soon.

T124752 [RFC] Expiring watch list entries (Daniel): Iterating on the design, discussion on the task.

T113034 RFC: Overhaul Interwiki map, unify with Sites and WikiMap (Daniel): Has been discussed before, needs somebody to actually take this on.

T114444 [RFC] Introduce notion of DOM scopes in wikitext (Tim)

There was a recap in last week's meeting (I wasn't there; more complete notes)

Per ArchCom member:

  • Gabriel:
    • T129435 RFC: drop support for running without mbstring (Gabriel): Very focused RFC by Max. Main question in discussion so far is whether polyfilling is worth it. Max reaching out to mediawiki-l.
  • Roan
    • T108655 Standardise on how to access/register JavaScript interfaces (Roan): No update since last week, I need to split this task but I haven’t had time to yet. Last week’s update: Considering to split out contentious part (file-based require, or something like it; to support embedding libraries), move forward on less controversial part (basic module-name-based require infrastructure)
  • Timo
    • T18691 RFC: Section headings should have a clickable anchor (Timo): Under discussion with Volker and Frontend Standards Group. Volker and team to collect different benefits and concerns to determine whether this is generally a desirable feature. And to explore other conceptually different solutions to the underlying use case of “sharing a link to a section” (e.g. a better table of contents, or live address bar).
  • Brion
    • T128351 RfC: Notifications in core (Brion): No movement last week. Needs clarification of interfaces & scope as follow-up from IRC meeting.
    • T66214 Use content hash based image / thumb URLs & define an official thumb API (Brion): Clarified requirements & priorities in last week's IRC discussion. Needs update to reflect discussion.
    • T118517 [RFC] Use <figure> for media (Brion): Revisit soon.
  • Daniel
    • T88596 Improving extension management (Daniel): Discussion is picking up again, patch for review.
    • T113034 RFC: Overhaul Interwiki map, unify with Sites and WikiMap (Daniel): Has been discussed before, needs somebody to actually take this on.
  • Tim
    • T114444 [RFC] Introduce notion of DOM scopes in wikitext (Tim): Active related discussion and prototyping at Balanced templates and Hygienic transclusions for WYSIWYG, incremental parsing & composition: Options and trade-offs.

Gabriel sent out the RFC summary from last week to wikitech-l: ArchCom RFC update

This week in {E157}, I asked Gabriel, Tim, and Timo what the most important RFC they were shepherding. Here's what their answers were:

  • Gabriel: Possibly T130567 or T114445, T114072
  • Tim: T114445 RFC:: Balanced templates
  • Timo (on behalf of Roan): T108655 Standardise on how to access/register JavaScript interfaces
  • Timo: T130663 RFC: Reference API requirements and options

There are more detailed notes for E157 that Gabriel and/or I will post to wikitech-l. In short, we think we have a reasonably solid plan for E159, which is documented in the event listing:

Qgil removed a subscriber: Qgil.Apr 7 2016, 6:24 AM
RobLa-WMF closed this task as Resolved.Apr 19 2016, 9:13 PM
RobLa-WMF claimed this task.

TechCom has implemented the policy of assigning shepherds, and all TechCom members currently . The ArchCom calendar now has all of our planning meetings in it, so updates are somewhat straightforward to find there.

Recent shepherd updates:

  • April 6 meeting - E157#1703
  • April 13 meeting - E161#1694

I'm going to stop posting shepherd updates to this task, and instead use the ArchCom Planning meeting events in Phab when I make updates in Phab.

Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptApr 19 2016, 9:13 PM
Qgil awarded a token.Apr 19 2016, 10:22 PM
Danny_B removed a subscriber: TechCom.
Krinkle moved this task from Under discussion to TechCom-Approved on the TechCom-RFC board.
Krinkle edited projects, added TechCom-RFC (TechCom-Approved); removed TechCom-RFC.
Krinkle moved this task from Untriaged to Implemented on the TechCom-RFC (TechCom-Approved) board.