Architecture meetings/RFC review 2013-09-24

From mediawiki.org

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

URL shortener service for Wikimedia[edit]

Support for user-specific page lists in core[edit]

Retained account data self-discovery[edit]

  • 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[edit]

Dropping actions in favour of special pages[edit]

LESS[edit]

<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[edit]

  • 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?