HomePhabricator

ArchCom RFC Meeting: Markdown support? (2016-06-22, #wikimedia-office)
ActivePublic

Hosted by daniel on Jun 22 2016, 9:00 PM - 10:00 PM.

Description

Meeting started by brion at 21:01:31 UTC. The full logs are available
at
https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-06-22-21.01.log.html
.

Meeting summary

  • ''LINK:'' https://phabricator.wikimedia.org/E218 Phab event for this week's meeting (robla, 21:02:19)
  • discussing https://phabricator.wikimedia.org/T137946 develop Markdown support strategy for MediaWiki (brion, 21:02:40)
  • ''LINK:'' https://www.mediawiki.org/wiki/Requests_for_comment/Markdown this week's RFC (robla, 21:03:20)
  • open question: reasons for choosing markdown? example: moving hosting of a github wiki (brion, 21:12:58)
  • open question: complexity and extensions to the markup? example: would we need a syntax extension for templates/parserfunctions/lua/wikidata/etc? (brion, 21:13:48)
  • for convertability of markdownish things, see pandoc http://pandoc.org/README.html#pandocs-markdown (brion, 21:15:26)
  • question: heavy use of wikitext in UI may require core parser. implications for alternate formats? (brion, 21:17:28)
  • ''LINK:'' https://phabricator.wikimedia.org/project/view/898/ VisualEditor copypaste component in Phab (robla, 21:18:27)
  • question: would cut-and-paste and interchange for markdown add a third editing mode beyond source/visual? (brion, 21:20:12)
  • tim sez "getting serious about multiple markup formats would led to cleaning up a lot of entagled cruft in core" (brion, 21:21:31)
  • whoops bd808 sez that (brion, 21:21:51)
  • tim is pretty sure ContentHandler can implement a markdown mode well. should already be well-factored. can be used as default contenthandler in theory (brion, 21:23:42)
  • example of needing core parser: messages in MediaWiki: namespace, such as site notices. force them to use wikitext CH (brion, 21:26:27)
  • i18n is heavily dependent on a subset of the core parser for plurals, genders, and other message variants... but that doesn't have to be used for content if you don't want (brion, 21:29:30)
  • question: is explicit versioning needed? can/should we make a 'wikitext 1.1' that is always implemented for i18n and ui messages? (brion, 21:32:52)
  • note i18n messages are a mix of plaintext+preprocess, HTML+preprocess, and pure wikitext (brion, 21:33:18)
  • question: implications of markdown choices on other tools like CT, need for i18n, and security? (brion, 21:35:59)
  • question is the HTML copy-paste "arms race" good enough vs markup-specific paste converter tools for markdown etc? (brion, 21:40:18)
  • ''LINK:'' https://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-12 (brion, 21:42:31)
  • for comparison, the HTML paste handling in VE is done by normalizing HTML on the VE end, before it eventually lands in parsoid during save/serialization (brion, 21:47:01)
  • ideally the parsoid html2wt would take any html and produce 'acceptable' wikitext but is not fully exercised at that right now (brion, 21:47:30)
  • an HTML-only storage world needs to carefully sanitize between "outside HTML" and "safe inside HTML".... but there's no spec! we'd need one (brion, 21:53:14)
  • ''LINK:'' https://en.wikipedia.org/wiki/HTML_email (robla, 21:54:38)
  • ''LINK:'' http://commonmark.org/ (robla, 21:57:47)
  • ''LINK:'' https://phabricator.wikimedia.org/T127329 related parsoid bridge for html-import-to-wikitext (brion, 21:58:50)
  • tim is skeptical of direct paste; html import seems to serve well (brion, 22:00:21)
  • ''ACTION:'' someone should revise the RfC, probably drop the cut-paste (brion, 22:00:43)
  • ''ACTION:'' update T112999 for the ContentHandler era (brion, 22:00:58)
  • ''ACTION:'' subbu will chat with cscott (brion, 22:01:36)

Meeting ended at 22:01:41 UTC.

Action items

  • someone should revise the RfC, probably drop the cut-paste
  • update T112999 for the ContentHandler era
  • subbu will chat with cscott

Action items, by person

  • subbu
    • subbu will chat with cscott
  • UNASSIGNED
    • someone should revise the RfC, probably drop the cut-paste
    • update T112999 for the ContentHandler era

People present (lines said)

  • brion (68)
  • robla (38)
  • subbu (34)
  • TimStarling (32)
  • bd808 (8)
  • stashbot (4)
  • YairRand (3)
  • wm-labs-meetbot` (3)
  • Scott_WUaS (3)

Log: P3299

Architecture meetings
13:00 PT ArchCom Planning Meetingsupcomingall since 2016-03-30
14:00 PT ArchCom-RFC Meetingsupcomingall since 2015-09-09

Recurring Event

Event Series
This event is an instance of E66: ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office), and repeats every week.

Event Timeline

RobLa-WMF renamed this event from ArchCom RFC Meeting: <topic TBD> (<see "Starts" field>, #wikimedia-office) to ArchCom RFC Meeting: Markdown support? (2016-06-22, #wikimedia-office).Jun 16 2016, 6:15 AM
RobLa-WMF updated the event description. (Show Details)
RobLa-WMF updated the event description. (Show Details)Jun 16 2016, 6:25 AM
jayvdb invited: ; uninvited: .Jun 17 2016, 4:39 AM
jayvdb added a subscriber: jayvdb.

<wm-labs-meetbot`> Meeting ended Wed Jun 22 22:01:41 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:01:42 W<wm-labs-meetbot`> Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-06-22-21.01.html
15:01:42 W<wm-labs-meetbot`> Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-06-22-21.01.txt
15:01:42 W<wm-labs-meetbot`> Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-06-22-21.01.wiki
15:01:42 W<wm-labs-meetbot`> Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-06-22-21.01.log.html

Log:

121:01:31 <brion> #startmeeting ArchCom RFC meeting - Markdown support | Wikimedia meetings channel | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/
221:01:31 <wm-labs-meetbot`> Meeting started Wed Jun 22 21:01:31 2016 UTC and is due to finish in 60 minutes. The chair is brion. Information about MeetBot at http://wiki.debian.org/MeetBot.
321:01:31 <wm-labs-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
421:01:31 <wm-labs-meetbot`> The meeting name has been set to 'archcom_rfc_meeting___markdown_support___wikimedia_meetings_channel___please_note__channel_is_logged_and_publicly_posted__do_not_remove_this_note____logs__http___bots_wmflabs_org__wm_bot_logs__23wikimedia_office_'
521:01:46 <brion> i hope that wasn't too many bits for poor meetbot
621:02:19 <robla> #link https://phabricator.wikimedia.org/E218 Phab event for this week's meeting
721:02:40 <brion> #info discussing https://phabricator.wikimedia.org/T137946 develop Markdown support strategy for MediaWiki
821:03:20 <robla> #link https://www.mediawiki.org/wiki/Requests_for_comment/Markdown this week's RFC
921:03:30 * robla wipes brow
1021:03:41 <brion> robla, care to chat a bit on the background?
1121:04:33 <robla> sure, this is asking "what should our Markdown strategy be?", where pretty much any answer is valid
1221:04:56 <brion> :D
1321:05:12 <robla> why I'm asking that: there are many, many flavors of "wiki syntax" out there, of which MediaWiki wikitext is only one
1421:06:00 <YairRand> (but ours is the _real_ wikisyntax... :P )
1521:06:04 <robla> many implementations claim "Markdown support", which the interpretation varies quite a bit based on implementation
1621:06:43 <robla> YairRand: :-D I think that actually gets to the heart of it
1721:07:52 <robla> YairRand: do you (or anyone out there) believe that all other implementations will "see the light" and start using our format? should they?
1821:08:59 <subbu> a different question is: will all the disparate markdown efforts to go beyond "simple" markdown eventually arrive at the wikitext level of complexity?
1921:09:25 <subbu> even if the syntax will probably not be wikitext syntax itself.
2021:09:59 <brion> (taking off my chair hat momentarily) what's a reason a given wiki might have for choosing to use markdown? preference, or compatibility with existing data or other tools, or?
2121:10:21 <brion> (that might affect how one would go about such support)
2221:10:56 <robla> I think both questions are very good, and now I'm having trouble choosing :-)
2321:11:00 <brion> :D
2421:11:08 <brion> let's do em in turn
2521:11:11 <bd808> migrating from a github wiki to mediawiki might be one reason to want markdown page source
2621:11:54 <brion> *nod*
2721:11:54 <robla> bd808: yup
2821:11:54 <YairRand> are there any serious limitations regarding wikitext that are solved in other syntaxes? are they pretty freely convertable?
2921:12:09 <Scott_WUaS> (Is there a question here about how Wikimedia markdown talked about now will interface with SQID and Wikidata?)
3021:12:35 <robla> YairRand: the Pandoc folks aspire to provide complete interchangability
3121:12:58 <brion> #info open question: reasons for choosing markdown? example: moving hosting of a github wiki
3221:12:59 <YairRand> robla: ... <clap clap clap>
3321:13:06 * subbu is looking at http://pandoc.org/README.html#pandocs-markdown and sees that it is a pretty long spec
3421:13:48 <brion> #info open question: complexity and extensions to the markup? example: would we need a syntax extension for templates/parserfunctions/lua/wikidata/etc?
3521:14:39 <brion> easy things are easy to convert, hard things are ....... well that's the question isn't it :D
3621:15:04 <subbu> one good reason to entertain this markdown question for mediawiki is that it might let us abstract the markup / parsing parts of the codebase behind an interface.
3721:15:26 <brion> #info for convertability of markdownish things, see pandoc http://pandoc.org/README.html#pandocs-markdown
3821:15:41 <TimStarling> what does cut and paste support mean for users in practice?
3921:15:52 <bd808> agreed. getting serious about multiple markup formats would led to cleaning up a lot of entagled cruft in core
4021:15:58 <brion> subbu: good point. also, how much do we rely on wikitext eg in the user interface?
4121:16:00 <subbu> i toyed with that interface idea in https://www.mediawiki.org/wiki/User:SSastry_(WMF)/Notes/Wikitext#Core_ideas
4221:16:35 <subbu> brion, yes, wikitext in the UI is tricky ...
4321:16:49 <subbu> site messages are another i guess.
4421:17:25 <robla> TimStarling: I know what it means for me, but that's probably a better question for the folks who work with VE regularly, since my understanding is that cut-n-paste bugs happen a lot
4521:17:28 <brion> #info question: heavy use of wikitext in UI may require core parser. implications for alternate formats?
4621:17:48 * robla goes to find the Phab component for cut-n-paste issues
4721:17:58 <subbu> brion, is this (wikitext in UI) used a lot in non-wmf installs of mediawiki?
4821:18:27 <robla> https://phabricator.wikimedia.org/project/view/898/ VisualEditor copypaste component in Phab
4921:18:29 <TimStarling> would markdown be a third editing mode, after "source" and VE?
5021:18:33 <robla> #link https://phabricator.wikimedia.org/project/view/898/ VisualEditor copypaste component in Phab
5121:19:00 <subbu> TimStarling, I would think not.
5221:19:12 <TimStarling> would you have an "insert markdown" toolbar button which gives you a box for pasting markdown?
5321:19:18 <brion> subbu: at least some yes, sentences and paragraphs allowing bold, links, etc on various special pages. don't know how scary they are
5421:19:27 <subbu> as in .. i see robla's proposal as that of using it as an interchange format for copy-paste
5521:20:12 <brion> #info question: would cut-and-paste and interchange for markdown add a third editing mode beyond source/visual?
5621:20:38 <TimStarling> <bd808> agreed. getting serious about multiple markup formats would led to cleaning up a lot of entagled cruft in core
5721:20:44 <TimStarling> or it could be done as a ContentHandler
5821:21:17 <bd808> yeah. then you could have a mixed wiki if you wanted
5921:21:29 <TimStarling> then you wouldn't even touch $wgParser or create a Parser base class
6021:21:31 <subbu> i don't see a used case for mixed-markup-format wikis.
6121:21:31 <brion> #info tim sez "getting serious about multiple markup formats would led to cleaning up a lot of entagled cruft in core"
6221:21:35 <subbu> that would be pretty confusing.
6321:21:44 <TimStarling> no, I was quoting bd808
6421:21:51 <brion> #info whoops bd808 sez that
6521:22:04 * brion quote parsing error ;)
6621:22:07 * bd808 denies it all
6721:22:41 <TimStarling> it can be the default content handler if you like, the point of doing it as a content handler is that it gives you a convenient pre-existing hook point
6821:22:53 <brion> i can see particular uses, such as when a wiki is used as a source repository of documents to be reused.... but they get scary ;)
6921:22:59 <brion> (for mixed modes)
7021:23:00 <TimStarling> pretty much everything about wikitext has already been abstracted there, for wikidata's benefit
7121:23:36 <TimStarling> things like links table updates, redirect syntax, PST and parsing itself
7221:23:42 <brion> #info tim is pretty sure ContentHandler can implement a markdown mode well. should already be well-factored. can be used as default contenthandler in theory
7321:23:48 <subbu> i see ...
7421:24:51 <bd808> that wouldn't effect site messages because the message system grabs onto $wgParser
7521:25:12 <bd808> but maybe that's not a bad thing
7621:25:17 <brion> but they'd still have to be written in wikitext if they are stored in a wiki page, right?
7721:25:19 <TimStarling> yeah, that's the point
7821:25:47 <TimStarling> site messages could have the wikitext content type, so you could even preview them using wikitext
7921:26:27 <TimStarling> we already support default content types that vary depending on namespace
8021:26:27 <brion> #info example of needing core parser: messages in MediaWiki: namespace, such as site notices. force them to use wikitext CH
8121:26:34 <TimStarling> again for wikidata's benefit
8221:26:34 <robla> is some sort of wikitext always going to be at the heart of MediaWiki or is T112999 forseeable?
8321:26:35 <stashbot> T112999: Let MediaWiki operate entirely without wikitext - https://phabricator.wikimedia.org/T112999
8421:27:09 <brion> robla: it's conceivable but we'd have to eliminate or make optional the remaining wikitext users ;)
8521:27:36 <subbu> brion, i don't think robla is saying get rid of wikitext .. but whether mediawiki might support an option without wikitext.
8621:27:48 <bd808> allowing the parser for site messages to change would be like adding a language variant to every i18n language which seems unlikely to turn out well
8721:28:22 <brion> right you'd basically have to change them to plaintext or plaintext with a very limited markup that is not full wikitext
8821:28:31 * subbu is trying to grok what bd808 just said
8921:28:34 <TimStarling> I don't think it would really be helpful to attempt to translate i18n into some other markup language
9021:28:46 <brion> but we've got all sorts of fun things like grammatical plural and gender markers done via a subset of wiki markup
9121:28:47 <TimStarling> you know, i18n really drove the development of a lot of parser features
9221:28:48 <bd808> subbu: en-wikitext && en-markdown
9321:29:30 <brion> #info i18n is heavily dependent on a subset of the core parser for plurals, genders, and other message variants... but that doesn't have to be used for content if you don't want
9421:29:36 <robla> let's say that the version of wikitext we have now is "wikitext 1.0". is "wikitext 1.1" something we could do? (and still support i18n)
9521:30:10 * brion ponders
9621:30:36 <brion> could we, or would we want to, split a wikitext spec into 'the bits used for i18n' and 'extra fancy-ass markup used in wikipedia-like content'
9721:30:37 <brion> ?
9821:30:45 <subbu> robla, wikitext has evolved over the years .. so, i guess the qn. you are asking is if explicit versioning is needed?
9921:30:48 <brion> or is that even worse :D
10021:30:49 <TimStarling> i18n of course is a mix of formats
10121:31:05 <TimStarling> preprocessed plain text, preprocessed HTML and true wikitext
10221:31:07 <brion> plaintext, plaintext plus, wikitext, html, .... oh helllllls
10321:31:14 <robla> subbu: yeah, I think so
10421:31:49 <TimStarling> well, except the qqq language which is pretty consistently wikitext
10521:32:52 <brion> #info question: is explicit versioning needed? can/should we make a 'wikitext 1.1' that is always implemented for i18n and ui messages?
10621:33:18 <brion> #info note i18n messages are a mix of plaintext+preprocess, HTML+preprocess, and pure wikitext
10721:34:42 <TimStarling> robla, are you proposing any role for markdown on WMF wikis?
10821:35:10 <Scott_WUaS> (What are the implications of these MediaWiki markdown choices/decisions re ContentTranslation and Wikipedia's 358 languages, and security questions especially?)
10921:35:47 <robla> TimStarling: I think it potentially has a role in normalizing CopyPaste issues, but the path toward that is complicated
11021:35:59 <brion> #info question: implications of markdown choices on other tools like CT, need for i18n, and security?
11121:36:19 <subbu> that requires browsers, doc-creating systems (word, etc.) to support conversion to "standard" markdown.
11221:36:45 <TimStarling> it seems very limited as an interchange format
11321:37:02 <TimStarling> compared to RTF, HTML, PDF, etc.
11421:37:22 <brion> if I were going to copy-paste from a markdown wiki page, bug report, or readme file on github for instance, my choices are to copy-paste the source, or copy-paste the rendered HTML
11521:37:39 <robla> subbu: I think at a base level, we have a number of applications that claim "text/html" during copy/paste operations, but text/html copy pasting pretty much anything
11621:37:52 <brion> we know that pasting text/html is way harder than it should be ;) but we already support it in VE
11721:38:07 <subbu> brion, from some sources, yes.
11821:38:13 <TimStarling> pasting HTML into VE is already good enough to be useful
11921:38:14 <robla> brion: we support it today, but it's an arms race, isn't it?
12021:38:17 <brion> benefits of source copy?
12121:38:18 <TimStarling> I have used it a few times
12221:38:19 <brion> hehe yep
12321:39:00 <robla> no one (that I'm aware of) has defined a useful subset of HTML that is safe for copy/paste operations
12421:39:08 <brion> but so is markdown isn't it?
12521:39:22 <brion> if we support github's extensions, next we get asked about someone else's extensions
12621:40:18 <brion> #info question is the HTML copy-paste "arms race" good enough vs markup-specific paste converter tools for markdown etc?
12721:40:36 <TimStarling> HTML paste is likely to work if the HTML is very simple
12821:41:00 <TimStarling> for example if you're copying from a github README.md you'd expect it to work
12921:41:29 <robla> TimStarling: is there a "very simple" subset of HTML we can get browser makers to support?
13021:41:43 <robla> (for copy/paste purposes)?
13121:41:47 <subbu> robla, you linked to https://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-12 ... what are your thoughts on how likely it is to be adopted?
13221:42:24 <TimStarling> robla: no... but then browsers can't export to markdown either
13321:42:31 <brion> #link https://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-12
13421:42:55 <robla> subbu: I think like that could happen
13521:43:18 <subbu> our original goal for parsoid html2wt (which is still there as a comment in the serialization code) is to be able to accept arbitrary html and convert it to "acceptable" wikitext. but we haven't quite worked on that goal for a while now since we are mostly behind clients whose output is more controlled.
13621:44:05 <robla> subbu: what do you mean by "output is more controlled"?
13721:44:27 <subbu> as in .. VE/CX/Flow etc. don't generate arbitrary html.
13821:44:39 <robla> ah, got it
13921:45:25 <subbu> but, if you say, took the html from a bbc article and gave it to parsoid to convert to wikitext, the output isn't pretty.
14021:45:35 <robla> so...basically, the copy/paste code works when we can control the generation of the HTML, but most implementations don't conform to our spec
14121:45:51 <subbu> no, VE does its own handling of copy-pasted HTML .. it doesn't go through parsoid.
14221:46:20 <brion> fun :D
14321:46:29 <TimStarling> you mean it cleans up the HTML before it hands it to parsoid for serialization?
14421:46:41 <subbu> but, we've talked about creating a library for normalization and cleanup.
14521:47:01 <brion> #info for comparison, the HTML paste handling in VE is done by normalizing HTML on the VE end, before it eventually lands in parsoid during save/serialization
14621:47:10 <subbu> TimStarling, as far as i know ... they strip unrecognized / unsupported attributes.
14721:47:30 <brion> #info ideally the parsoid html2wt would take any html and produce 'acceptable' wikitext but is not fully exercised at that right now
14821:49:28 <robla> things like html2wt are going to be necessary for a long time, I imagine, but it seems to me we should at least start pulling people toward a world where html2wt isn't necessary
14921:50:32 <brion> well, there's the html-only world possibility :)
15021:50:47 <brion> where you'd still have some validation stage
15121:50:56 <brion> but not a major reparse i guess
15221:51:14 <brion> (and presumably a stage to handle composition of templates, media etc)
15321:51:56 <subbu> for parsoid to accept arbitrary html, we would need to run a sanitization pass on the html and strip unrecognized attributes, normalize html, etc.
15421:52:09 <robla> I think we live in a world where wikitext is sanitized and tries to be safe, and HTML is known unsafe
15521:52:28 <brion> indeed we'd have "inside html" and "outside html" at the least
15621:52:32 <subbu> which is also something that needs to happen with a html-only wiki .. sanitization at the very least.
15721:52:32 <brion> never, EVER mix em :D
15821:52:44 <robla> there's no "sanitized HTML" spec
15921:53:09 <subbu> :)
16021:53:14 <brion> #info an HTML-only storage world needs to carefully sanitize between "outside HTML" and "safe inside HTML".... but there's no spec! we'd need one
16121:53:37 <robla> there's the old HTML email spec
16221:53:58 <robla> (but yeah, that's not really a good alternative)
16321:54:38 <robla> https://en.wikipedia.org/wiki/HTML_email
16421:55:34 <brion> probably we need to spec out our extensions as well, such as how you extract the file name from a usage, a wiki page from a link, a template reference and parameter set from a big ol' blob of divs or whatever
16521:55:46 <TimStarling> I think if VE's HTML paste can produce reasonable wikitext markup for any HTML generated from original markdown, then that more or less replaces the need for direct markdown paste
16621:56:15 <brion> i tend to agree
16721:56:36 <TimStarling> "original markdown" as in http://daringfireball.net/projects/markdown/syntax
16821:56:45 <TimStarling> which is much simpler than pandoc markdown
16921:57:28 <robla> commonmark would be the modern simple version, I think
17021:57:47 <robla> http://commonmark.org/
17121:57:50 <brion> ok we're getting low on time
17221:58:09 <brion> any action items to pursue? decisions made?
17321:58:21 <subbu> T127329 is the placeholder for the parsoid side work to consolidate html-import/cleanup code into a library for use by whoever.
17421:58:21 <stashbot> T127329: Using Parsoid as a wikitext bridge for importing content into wikitext format - https://phabricator.wikimedia.org/T127329
17521:58:50 <brion> #link https://phabricator.wikimedia.org/T127329 related parsoid bridge for html-import-to-wikitext
17621:59:19 <Scott_WUaS> Thanks All!
17721:59:26 <TimStarling> so I'm fairly skeptical about the idea of direct markdown paste as being superior to markdown->html->wikitext
17821:59:28 <robla> subbu: my understanding is that you're working on RFCs as a goal soon, right?
17921:59:28 <subbu> i was interested in the markdown strategy as a potential benefit for refactoring some code in mediawiki .. but looks like that is mostly already in place?
18021:59:50 <brion> yay wikidata -> contenthandler \o/
18122:00:17 <subbu> robla, rfcs for .. that task i pasted above?
18222:00:21 <brion> #info tim is skeptical of direct paste; html import seems to serve well
18322:00:33 <robla> subbu: something related to T112999?
18422:00:34 <stashbot> T112999: Let MediaWiki operate entirely without wikitext - https://phabricator.wikimedia.org/T112999
18522:00:43 <brion> #action someone should revise the RfC, probably drop the cut-paste
18622:00:44 <subbu> ah, cscott territory.
18722:00:49 <subbu> yes.
18822:00:58 <brion> #action update T112999 for the ContentHandler era
18922:00:58 <stashbot> T112999: Let MediaWiki operate entirely without wikitext - https://phabricator.wikimedia.org/T112999
19022:01:15 <subbu> i'll chat with him about it.
19122:01:36 <brion> #action subbu will chat with cscott
19222:01:38 <brion> thanks all!
19322:01:41 <brion> #endmeeting

RobLa-WMF updated the event description. (Show Details)Jun 22 2016, 10:38 PM
jayvdb updated the event description. (Show Details)Jul 4 2016, 4:13 AM
daniel renamed this event from ArchCom RFC Meeting: Markdown support? (2016-06-22, #wikimedia-office) to ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office).Nov 21 2016, 6:11 PM
daniel changed the host of this event from RobLa-WMF to daniel.
daniel uninvited: jayvdb.
daniel updated the event description. (Show Details)
daniel updated the event description. (Show Details)Dec 9 2016, 7:43 AM
daniel renamed this event from ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office) to ArchCom RFC Meeting: Markdown support? (2016-06-22, #wikimedia-office).