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?

In T125865#2010724, @RobLa-WMF wrote:

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.

In T125865#2011301, @MZMcBride wrote:

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 header "share" link

@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:

• @GWicke - T124365 REST API versioning
• @brion: T118517 [<figure> usage], maybe T120414 [editor plugin registry]?
• @Catrope - still considering
• @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: T468 RfC: CentralNotice backend improvements

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).

Query for RFCs by shepherd: https://phabricator.wikimedia.org/maniphest/query/xc.j4DEYcjwu/

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:

• E159: RFC Meeting: Hygienic transclusions and balanced templates (2016-04-13, #wikimedia-office)