Architecture meetings/RFC review 2013-09-24

RFC review meeting over IRC on 2013-09-24. RFCs discussed:

• URL shortener (discussion transcript)
• Support for user specific page lists in core (discussion transcript)
• Retained account data self-discovery (discussion transcript)

URL shortener service for Wikimedia

• https://www.mediawiki.org/wiki/Requests_for_comment/URL_shortener
  • Tim's idea: https://www.mediawiki.org/wiki/Talk:Requests_for_comment/URL_shortener#Tim.27s_implementation_suggestion
  • Brion, Chad, Roan in favour of rewriting the RFC along the lines of Tim's proposal
  • note page 18 of https://commons.wikimedia.org/wiki/File:WMF%27s_New_Global_South_Strategy.pdf for language communities to consult?
• Agreed: next step Tim will check in with the authors and update the RfC. We'll continue discussion through ML and talk page after that.

Support for user-specific page lists in core

• https://www.mediawiki.org/wiki/Requests_for_comment/Support_for_user-specific_page_lists_in_core
  • SWalling & Deskana ought to look at this to figure out priority?
• brion suggests looking at the UX to build around this -- at least make a plan. Otherwise users will make up their own, which may be interesting. :)
• <ori-l> I think that editors already have different use-cases in mind when they watchlist a page, we just don't have any support in the software for it <ori-l> there's watch this page because i am its primary author and want to see how it grows, there's watch this talk page to know when someone replies, watch this page because it gets vandalized often, etc.
• general agreement that this needs more thought and work before we can all sign off on it, but the core idea is good
• old patch from last year's GSOC: https://gerrit.wikimedia.org/r/#/c/16419/ / blog from last year's GSOC: http://mw-watchlist.tumblr.com/
  • https://www.mediawiki.org/wiki/User:Blackjack48 https://www.mediawiki.org/wiki/Summer_of_Code_Past_Projects#Watchlist_grouping_and_workflow_improvements - in case Ori & Steven want to reach out to him

Retained account data self-discovery

• https://www.mediawiki.org/wiki/Requests_for_comment/Retained_account_data_self-discovery
• security question: danger of leaking private details when accounts are compromised?
• process question: beyond a technical recommendation (is/isn't feasible, is/isn't a good idea for security or perf reasons) I don't think we can make the call of whether this is something Wikimedia should do. As a process matter, who/where to we kick this up to?
  • Tim suggests getting some review from legal
  • but who should make a final decision?
• decision: clarify and expand RFC, request legal opinion
  • (next step? we don't know yet but let's revisit)

Data store

• https://www.mediawiki.org/wiki/Requests_for_comment/DataStore

Dropping actions in favour of special pages

• https://www.mediawiki.org/wiki/Requests_for_comment/Drop_actions_in_favour_of_page_views_and_special_pages

LESS

<brion> we might start with one I just accepted/merged -- the LESS styles support <brion> any remaining questions about the process, what seemed to work or didn't work?

• Overall: I think the RFC process worked very well here. I don't think it would have gone through otherwise. Having Brion endorse the patch actually set the stage for adoption / acceptance by the developer community -- or at least that's my hope / expectation.
• Slightly confusing: what is the relationship between the RFC and the patch? Once the implementation seemed *generally* sound, should it have been accepted? I was a bit stressed out by having the very idea of using LESS in existential doubt while at the same time ironing out fairly minor issues. It may have been better to say "OK, accepted", but decouple the patch from that. On the other hand, if the two were decoupled, it's possible the patch would have lingered on for another year without anyone having the requisite courage to pull the trigger.

General notes

• We might want a 'provisional' or 'in implementation' state on RfCs to indicate 'people generally agree with implementing this and serious work is under way
  • I think we should encourage code to accompany RfCs unless they really are in the "is this even a good idea at all?" stage
    • generally yes! of course we can always expect to change that code in response to review and further ideas...

Meta notes on the discussion: email lists, IRC notes didn't always make it back to the RfC discussion page. Are we losing data when we split discussions?

• list is useful because of larger audience
• recommendation to ... cross-reference?