Discussion notes captured at E325: ArchCom RFC Meeting W43: Allow HTML in SVG? (2016-10-26, #wikimedia-office)

15:00:08 <wm-labs-meetbot> Meeting ended Wed Oct 26 22:00:07 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:00:08 <wm-labs-meetbot> Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-10-26-21.01.html
15:00:08 <wm-labs-meetbot> Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-10-26-21.01.txt
15:00:08 <wm-labs-meetbot> Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-10-26-21.01.wiki
15:00:08 <wm-labs-meetbot> Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-10-26-21.01.log.html

More nicely formatted version of the notes over here: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016/ApiUsability

This session should be a followup to last year's T122818

Notes from this session:

In T122942#2244988, @RobLa-WMF wrote (on 2016-04-27):

To summarize @cscott's last comment (T122942#2241839), the solutions suggested in this RFC are:

• Candidate solution #1 - Domains
  • According to T122942#2241839 - "non starter"
• Candidate solution #2 - Path prefixes
  • Possible?
• Candidate solution #3 - special endpoint for variant conversion
  • Possible?
• Candidate solution #4 - query string
  • According to T122942#2241839 - problematic from a caching standpoint

Great conversation yesterday about this topic. See E323 for the semi-automated summary of the discussion.

This was the log for E323, which was about T145472

Thank you for the writing prompt, @MelodyKramer ! I ended up plagiarizing large portions of your text, and sending it to the Pandoc mailing list (a copy of my email). Rumor has it that it resulted in at least one new registration, and I'm hoping more to come.

15:00:07 <wm-labs-meetbot> Meeting ended Wed Oct 19 22:00:07 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:00:07 <wm-labs-meetbot> Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-10-19-21.03.html
15:00:07 <wm-labs-meetbot> Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-10-19-21.03.txt
15:00:07 <wm-labs-meetbot> Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-10-19-21.03.wiki
15:00:07 <wm-labs-meetbot> Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-10-19-21.03.log.html

In T138783#2727342, @matmarex wrote:

No, we don't want to parse wikitext in SVG images, that's far too crazy :) But I think Sanitizer can just sanitize HTML, and we could prevent the upload if it's not acceptable.

In T138783#2725870, @MothsART wrote:

I've generated this illustration with a custom tool.
This tool (a wysiwyg and an offline web app) can import a static <svg> (no smil, javascript and foreign objects) and add a legend with descriptions.[...] I've personnally added a <switch> node on generated process.
However, to edit descriptions (foreign objets product), i've used a wysiwyg editor (a lighter http://alex-d.github.io/Trumbowyg/).

In T147602#2724937, @cscott wrote:

Sure. Let me bring it up to date, though; maybe a new task would be best.

@cscott - do you want to revive T112996 for Wikimedia-Developer-Summit (2017)?

We have this tentatively planned as our IRC meeting topic for this Wednesday:

I wanted to make sure to note that several of us have been discussing this on wiki as well: https://www.mediawiki.org/wiki/Talk:Requests_for_comment/JSON_validation

I took the liberty of adding @daniel as a co-facilitator for this area as a response to Daniel's on-wiki comment. Daniel, I think this would be the topic for us to drill down on content model related work.

In T2384#1752696, @saper wrote:

I'd like to propose changing this to a Phabricator project.

@scfc and @saper are listed on https://www.mediawiki.org/wiki/Developers/Maintainers as developers for PostgreSQL support and might be able to help.

In T138783#2719191, @MothsART wrote:

I'm not a draw.io user but i have the same limitation to upload svg files with foreign objects.

I suggest a real example : https://github.com/mothsART/labodunerd/blob/master/labo/frontend/interactive_svg/campement.min.foreign.svg

I precise, than the foreign object is encapsulated in a <switch> parent with an alternate <text> node when foreign objects are not supported.

I don't really understand the restriction on "http://www.w3.org/1999/xhtml" namespace except in the <iframe> context => treated on
https://github.com/wikimedia/mediawiki/blob/master/includes/upload/UploadBase.php#L1475-L1480 ?

Thanks for filing this @binbot, and thanks for starting the "Long summary upon reverting an IPv6 anon" discussion on wikitech-l. As you noted, the previous editor's fully linked name is an unfortunate truncation. The article where we can see this happening is the page history of huwiki:Újrahasznosítás

T147177 seems really relevant to this topic. @chasemp and @bd808 are listed as facilitators but it's noted "it would be better to have volunteer developer driving this main topic". Would @Hydriz be a logical person to ask? Assuming the answer is "yes", then the natural next question: @Hydriz, is this something you'd be interested in helping with?

In order to understand if rMWaa5be0c1e03d is a safe change, I'd need to better understand the problem @aaron was trying to fix with rMW2be60e777a09, which introduced the setValidationHash call that @Ejegg is changing. Understanding that myself is a little out of my depth, but I'm hoping y'all understand this given the proposed modifications.

Last year, @MrStradivarius suggested "Standardise procedures for deprecating public-facing code" (T114384) as a topic for Wikimedia-Developer-Summit-2016. Since his initial proposal, the topic hasn't exactly been solved. We have T121204 and T146965, and we at WMF are struggling with how to deal with deployed components that don't have clear owners (see T128370).

I see Cassandra, CouchBase, Riak, HBase, and HyperDex listed on the wiki page.

In T139300#2712491, @Aklapper wrote:

Thanks for working on this!
Once merged and dust has settled, https://gerrit.wikimedia.org/r/#/c/211034/ should get abandoned I guess?

@Huji, thank you for stepping up! This particular area of code is going to deserve extra scrutiny during elections, so I'd like to ensure I'm not the only person looking at @Huji's request. I haven't looked at this area of code and haven't been involved in the Wikimedia election process for a couple of years, and there could be ramifications that I haven't fully considered. Thus, my support does come with that caveat. I love the idea of someone outside of WMF stepping up and assuming this responsibility.

IRC log for E316: ArchCom RFC Meeting W41: CREDITs (2016-10-12, #wikimedia-office)

14:59:17 <wm-labs-meetbot`> Meeting ended Wed Oct 12 21:59:17 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
14:59:18 <wm-labs-meetbot`> Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-10-12-21.00.html
14:59:18 <wm-labs-meetbot`> Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-10-12-21.00.txt
14:59:18 <wm-labs-meetbot`> Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-10-12-21.00.wiki
14:59:18 <wm-labs-meetbot`> Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-10-12-21.00.log.html

I had vaguely recalled in a conversation with someone (@bd808 perhaps?) that "I think getCanonicalName is my fault". This may be my earliest contribution to MediaWiki (which I rediscovered via git as e4480a80afb7).

@Qgil, thanks for establishing the "Facilitate WikiDev" topic pattern with T147406. We now following that pattern for half of the topics:

@Huji wrote:

The el_owner field should instead be populated with the user ID of the user who creates the poll. That way we won't have issues with strict mode either.

Thanks @Huji for noting the SecurePoll strict mode problems (T147875).

@Huji - excellent! My apologies for making assumptions about @Anomie being the last active contributor. As for ownership, the requirements are very loosely defined, but demonstrating that you're responsive and motivated helps make the case that we should treat you as an owner.

@Anomie: do you have an idea of how difficult it would be to complete this? I'm not asking you to do it, just wanting to understand how large the maintenance task might be.

In T147593#2706576, @jcrespo wrote:

@chasemp Yes, I even have slides prepared (those are too many, but to mark it would take me no time):

http://www.slideshare.net/jynus/mysql-schema-design-in-practice
http://www.slideshare.net/jynus/query-optimization-from-0-to-10-and-up-to-57

In T146307#2696140, @Legoktm wrote:

I think wikitech-l should always receive last call announcements. wikitech-ambassadors maybe if it is relevant.

I think we could add a |status=lastcall parameter to {{rfc}} plus the category to generate a "RfCs in Last call" listing on https://www.mediawiki.org/wiki/Requests_for_comment for example.

We should do this. Phab events are designed for meetings, so even without the .ics support, this would be helpful.

@anirudh24seven, could you add a comment on Commons_talk:Mobile_app expressing your desire to revive the app?

@Rfarrand here's what we advised "scribes" to do in last year's checklist:

@Jdlrobson: ArchCom discussed this as a possible topic for next week's IRC meeting (E316 2016-10-12, Wednesday 2pm PDT). Do you think that's a good idea? Relatedly, are you available at that time?

Discussed at E287: ArchCom RFC Meeting W40: Future of magic links. (2016-10-05, #wikimedia-office). Important bits of the summary:

• AGREED: 1. Disable the magic link functionality by default for the MediaWiki 1.28 release (TimStarling, 21:56:26)
• AGREED: 2. Deprecate magic links on Wikimedia wikis (e.g. Wikipedia), providing alternatives for this functionality and tools to aid the migration (TimStarling, 21:56:58)
  • note: some nuance around this agreement was discussed in the full log below (lines 202-208)
• no consensus on removing the functionality from MW or flagging its pending removal via deprecation (TimStarling, 21:58:35)

This was for E287: ArchCom RFC Meeting W40: Future of magic links. (2016-10-05, #wikimedia-office)

<wm-labs-meetbot> Meeting ended Wed Oct 5 22:02:45 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:02:45 W<wm-labs-meetbot> Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-10-05-21.01.html
15:02:45 W<wm-labs-meetbot> Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-10-05-21.01.txt
15:02:45 W<wm-labs-meetbot> Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-10-05-21.01.wiki
15:02:45 W<wm-labs-meetbot> Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-10-05-21.01.log.html

One note for myself: as part of completing this task, I'd like to move https://www.mediawiki.org/wiki/User:RobLa-WMF/Wikitech-l to https://www.mediawiki.org/wiki/Wikitech-l , since I believe that wikitech-l is important enough to MediaWiki that it should have page on MediaWiki.org describing this list and its role as "paper of record" for last call announcements (assuming we keep this on wikitech-l)

In T147158#2684521, @matmarex wrote:

I honestly don't think introducing YAML content would further your goal of making editing that content easier. We should try to define the format we really want (either as subset of YAML, or superset of JSON) and implement a parser for it. Has no one really specified a "JSON-with-comments-and-trailing-commas" anywhere on the internet before? It feels unlikely that we'd be the first people to have this problem…

In T146307#2676260, @Legoktm wrote:

Were any alternatives proposed?

In T145604#2683645, @Legoktm wrote:

In T145604#2675172, @RobLa-WMF wrote:

We think this might even be ripe for our IRC discussion next week (at E287)

Thanks, that would be great. Just a heads up that I'm back in school now, and am unable to make the Wednesday meeting times due to class :( I'm fine with this being discussed in my absence or I'm also available Tuesday/Thurs at the same time.

I get where Yuri is coming from. YAML's comments and more flexible handling of formatting make it a more interesting format for hand crafting. The idea of allowing a more forgiving format for text entry is appealing. Also, comments.

Thanks for the ping on this! I think this topic relates to all this:
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/How_to_manage_our_technical_debt