Architecture committee/2016-05-18

Agenda timeline

 * Intro
 * Agenda bashing and action item check 21:00 (5 minutes)
 * Last week+this week’s RfC office hour 21:05 (5 minutes)
 * RFC status update
 * RfC inbox triage 21:10 (10 minutes)
 * Shepherd assignments 21:20 (5 minutes)
 * Queue for future RfC office hours 21:25 (5 minutes)
 * Wrapup
 * Other business 21:30 (10 minutes)
 * Next week’s ArchCom agenda 21:40 (10 minutes)

Intro section

 * 10 minutes (starting 21:00 UTC)


 * Action items
 * Last week
 * ACTION: RobLa: create #ArchCom-Approved tag (T133803) (done)
 * ACTION: Tim to talk to Chris, Darian, and Brian about meeting frequency
 * ACTION: RobLa - make compelling agenda for next week.
 * Last week’s RfC office hour
 * E171: RFC: Overhaul Interwiki map, unify with Sites and WikiMap (T113034)
 * Summary here: T113034#2287772
 * In short: We agreed that there's no reason to go to last call, because we weren't making a final decision.

RFC status update
20 minutes (starting 21:10 UTC)

Spend roughly 20 minutes ensuring Architecture committee/Status is up-to-date. Checklist of the questions we should answer:
 * Who is chairing the upcoming IRC meeting? Tim chairing, Rob “shepherding”
 * Conclude last week's "final comment period"? Do we have anything that should enter "final comment"?
 * Daniel was hoping for go-ahead to start implementing the direction described in T113034.  He thought a “sub RFC” might have made it clearer, but was more overhead.
 * RobLa preferred single RFC, but isn’t comfortable with “approved” to describe our discussion.  Just agreeing that the work so far is “heading in the right direction”
 * Daniel asked if “on track” made sense, which RobLa liked, and thought would make a good workboard state. Gabriel said the danger here is renaming “under discussion” to “on track”.  RobLa tabled the discussion to allow more time to think about it.
 * Do we have a robust queue of RFCs to discuss at future IRC discussions?
 * RobLa pointed out that we don’t have a queue right now.  Daniel reminded us that we have
 * For each upcoming meeting, do we anticipate the RFC moving into "final comment"?
 * How does ArchCom-RfCs board look?
 * Where should anything in the inbox go?
 * What is the most important thing each ArchCom member is shepherding? Anything blocked? Are responsibilities balanced well?
 * Daniel
 * Been pretty busy with interwiki, multi-content revision stuff
 * T88596 - (extension management) may be stalled, will move
 * Still wants to follow up on quality
 * Gabriel
 * Proposed T132597 (RFC: Agree on endpoints for feeds) for “final comment”, as posted on wikitech-l.  Since ArchCom hadn’t discussed or had time to consider this, the other members didn’t.
 * Roan
 * Busy fixing T3066 (cross-wiki talk page notification), so hasn't had time to shepherd RFCs
 * Rob
 * Still need to schedule an RFC triage meeting outside of ArchCom-RFC time
 * Filed T135674, and made it clear that I'm not going to be able to do this without some help.
 * Created #ArchCom-Approved Phab tag (T133803) as milestone, with help from JAufrecht
 * Tim
 * Not many updates with cscott on vacation.  T89331 (Replace Tidy in MW parser with HTML 5 parse/reserialize)
 * T114444 - Introduce notion of DOM scopes in wikitext
 * No updates: Timo
 * The inbox
 * T107561 - MediaWiki support for  - needs shepherd
 * Daniel pointed out this is an old one.  May need to go into “needs shepherd”.
 * Next week: triage!

Other business/planning
20 minutes (starting 21:30 UTC) generated from Architecture committee/MeetingNoteTemplate
 * We discussed some aspects of Security working group we’re thinking about, but can’t talk about them yet because security.
 * We came back to the process issues we touched on during Gabriel’s update, where we discussed the speed which we should move RFCs through the process.  Kevin Smith asked if ArchCom turned away any RFC because it was too small.  RobLa’s hunch is “yes”, and Tim believes we untagged a couple which didn’t have the level of detail necessary.  We don’t yet have consensus or clear guidance on when it’s appropriate to consult ArchCom (and when it isn’t).  That will depend in part on whether we want people to come to ArchCom for advice (quick), vs. approval/endorsement (longer)?