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

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

Description

Location: #wikimedia-office IRC channel
Meeting type: TBD
Time: 2016-06-22, Wednesday 21:00 UTC (2pm PDT, 23:00 CEST)
Agenda:
- Tentative: T137946: RFC (WIP): develop Markdown support strategy for MediaWiki

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 Meetings	upcoming	all since 2016-03-30
14:00 PT ArchCom-RFC Meetings	upcoming	all since 2015-09-09

Recurring Event
Next
Previous

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

Details

Invitees

TechCom
• RobLa-WMF
JanZerebecki
MarkAHershberger
daniel

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 subscribed.

• RobLa-WMF mentioned this in T137946: RFC (WIP): develop Markdown support strategy for MediaWiki.Jun 21 2016, 3:26 AM

Scott_WUaS subscribed.Jun 22 2016, 9:07 PM

<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:

P3299 ArchCom-RFC-2016W25-irc-E218.txt

1	21: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/
2	21: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.
3	21:01:31 <wm-labs-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
4	21: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_'
5	21:01:46 <brion> i hope that wasn't too many bits for poor meetbot
6	21:02:19 <robla> #link https://phabricator.wikimedia.org/E218 Phab event for this week's meeting
7	21:02:40 <brion> #info discussing https://phabricator.wikimedia.org/T137946 develop Markdown support strategy for MediaWiki
8	21:03:20 <robla> #link https://www.mediawiki.org/wiki/Requests_for_comment/Markdown this week's RFC
9	21:03:30 * robla wipes brow
10	21:03:41 <brion> robla, care to chat a bit on the background?
11	21:04:33 <robla> sure, this is asking "what should our Markdown strategy be?", where pretty much any answer is valid
12	21:04:56 <brion> :D
13	21: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
14	21:06:00 <YairRand> (but ours is the _real_ wikisyntax... :P )
15	21:06:04 <robla> many implementations claim "Markdown support", which the interpretation varies quite a bit based on implementation
16	21:06:43 <robla> YairRand: :-D I think that actually gets to the heart of it
17	21: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?
18	21: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?
19	21:09:25 <subbu> even if the syntax will probably not be wikitext syntax itself.
20	21: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?
21	21:10:21 <brion> (that might affect how one would go about such support)
22	21:10:56 <robla> I think both questions are very good, and now I'm having trouble choosing :-)
23	21:11:00 <brion> :D
24	21:11:08 <brion> let's do em in turn
25	21:11:11 <bd808> migrating from a github wiki to mediawiki might be one reason to want markdown page source
26	21:11:54 <brion> nod
27	21:11:54 <robla> bd808: yup
28	21:11:54 <YairRand> are there any serious limitations regarding wikitext that are solved in other syntaxes? are they pretty freely convertable?
29	21:12:09 <Scott_WUaS> (Is there a question here about how Wikimedia markdown talked about now will interface with SQID and Wikidata?)
30	21:12:35 <robla> YairRand: the Pandoc folks aspire to provide complete interchangability
31	21:12:58 <brion> #info open question: reasons for choosing markdown? example: moving hosting of a github wiki
32	21:12:59 <YairRand> robla: ... <clap clap clap>
33	21:13:06 * subbu is looking at http://pandoc.org/README.html#pandocs-markdown and sees that it is a pretty long spec
34	21: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?
35	21:14:39 <brion> easy things are easy to convert, hard things are ....... well that's the question isn't it :D
36	21: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.
37	21:15:26 <brion> #info for convertability of markdownish things, see pandoc http://pandoc.org/README.html#pandocs-markdown
38	21:15:41 <TimStarling> what does cut and paste support mean for users in practice?
39	21:15:52 <bd808> agreed. getting serious about multiple markup formats would led to cleaning up a lot of entagled cruft in core
40	21:15:58 <brion> subbu: good point. also, how much do we rely on wikitext eg in the user interface?
41	21:16:00 <subbu> i toyed with that interface idea in https://www.mediawiki.org/wiki/User:SSastry_(WMF)/Notes/Wikitext#Core_ideas
42	21:16:35 <subbu> brion, yes, wikitext in the UI is tricky ...
43	21:16:49 <subbu> site messages are another i guess.
44	21: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
45	21:17:28 <brion> #info question: heavy use of wikitext in UI may require core parser. implications for alternate formats?
46	21:17:48 * robla goes to find the Phab component for cut-n-paste issues
47	21:17:58 <subbu> brion, is this (wikitext in UI) used a lot in non-wmf installs of mediawiki?
48	21:18:27 <robla> https://phabricator.wikimedia.org/project/view/898/ VisualEditor copypaste component in Phab
49	21:18:29 <TimStarling> would markdown be a third editing mode, after "source" and VE?
50	21:18:33 <robla> #link https://phabricator.wikimedia.org/project/view/898/ VisualEditor copypaste component in Phab
51	21:19:00 <subbu> TimStarling, I would think not.
52	21:19:12 <TimStarling> would you have an "insert markdown" toolbar button which gives you a box for pasting markdown?
53	21: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
54	21:19:27 <subbu> as in .. i see robla's proposal as that of using it as an interchange format for copy-paste
55	21:20:12 <brion> #info question: would cut-and-paste and interchange for markdown add a third editing mode beyond source/visual?
56	21:20:38 <TimStarling> <bd808> agreed. getting serious about multiple markup formats would led to cleaning up a lot of entagled cruft in core
57	21:20:44 <TimStarling> or it could be done as a ContentHandler
58	21:21:17 <bd808> yeah. then you could have a mixed wiki if you wanted
59	21:21:29 <TimStarling> then you wouldn't even touch $wgParser or create a Parser base class
60	21:21:31 <subbu> i don't see a used case for mixed-markup-format wikis.
61	21:21:31 <brion> #info tim sez "getting serious about multiple markup formats would led to cleaning up a lot of entagled cruft in core"
62	21:21:35 <subbu> that would be pretty confusing.
63	21:21:44 <TimStarling> no, I was quoting bd808
64	21:21:51 <brion> #info whoops bd808 sez that
65	21:22:04 * brion quote parsing error ;)
66	21:22:07 * bd808 denies it all
67	21: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
68	21: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 ;)
69	21:22:59 <brion> (for mixed modes)
70	21:23:00 <TimStarling> pretty much everything about wikitext has already been abstracted there, for wikidata's benefit
71	21:23:36 <TimStarling> things like links table updates, redirect syntax, PST and parsing itself
72	21: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
73	21:23:48 <subbu> i see ...
74	21:24:51 <bd808> that wouldn't effect site messages because the message system grabs onto $wgParser
75	21:25:12 <bd808> but maybe that's not a bad thing
76	21:25:17 <brion> but they'd still have to be written in wikitext if they are stored in a wiki page, right?
77	21:25:19 <TimStarling> yeah, that's the point
78	21:25:47 <TimStarling> site messages could have the wikitext content type, so you could even preview them using wikitext
79	21:26:27 <TimStarling> we already support default content types that vary depending on namespace
80	21:26:27 <brion> #info example of needing core parser: messages in MediaWiki: namespace, such as site notices. force them to use wikitext CH
81	21:26:34 <TimStarling> again for wikidata's benefit
82	21:26:34 <robla> is some sort of wikitext always going to be at the heart of MediaWiki or is T112999 forseeable?
83	21:26:35 <stashbot> T112999: Let MediaWiki operate entirely without wikitext - https://phabricator.wikimedia.org/T112999
84	21:27:09 <brion> robla: it's conceivable but we'd have to eliminate or make optional the remaining wikitext users ;)
85	21:27:36 <subbu> brion, i don't think robla is saying get rid of wikitext .. but whether mediawiki might support an option without wikitext.
86	21: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
87	21: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
88	21:28:31 * subbu is trying to grok what bd808 just said
89	21:28:34 <TimStarling> I don't think it would really be helpful to attempt to translate i18n into some other markup language
90	21: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
91	21:28:47 <TimStarling> you know, i18n really drove the development of a lot of parser features
92	21:28:48 <bd808> subbu: en-wikitext && en-markdown
93	21: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
94	21: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)
95	21:30:10 * brion ponders
96	21: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'
97	21:30:37 <brion> ?
98	21:30:45 <subbu> robla, wikitext has evolved over the years .. so, i guess the qn. you are asking is if explicit versioning is needed?
99	21:30:48 <brion> or is that even worse :D
100	21:30:49 <TimStarling> i18n of course is a mix of formats
101	21:31:05 <TimStarling> preprocessed plain text, preprocessed HTML and true wikitext
102	21:31:07 <brion> plaintext, plaintext plus, wikitext, html, .... oh helllllls
103	21:31:14 <robla> subbu: yeah, I think so
104	21:31:49 <TimStarling> well, except the qqq language which is pretty consistently wikitext
105	21: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?
106	21:33:18 <brion> #info note i18n messages are a mix of plaintext+preprocess, HTML+preprocess, and pure wikitext
107	21:34:42 <TimStarling> robla, are you proposing any role for markdown on WMF wikis?
108	21: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?)
109	21:35:47 <robla> TimStarling: I think it potentially has a role in normalizing CopyPaste issues, but the path toward that is complicated
110	21:35:59 <brion> #info question: implications of markdown choices on other tools like CT, need for i18n, and security?
111	21:36:19 <subbu> that requires browsers, doc-creating systems (word, etc.) to support conversion to "standard" markdown.
112	21:36:45 <TimStarling> it seems very limited as an interchange format
113	21:37:02 <TimStarling> compared to RTF, HTML, PDF, etc.
114	21: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
115	21: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
116	21:37:52 <brion> we know that pasting text/html is way harder than it should be ;) but we already support it in VE
117	21:38:07 <subbu> brion, from some sources, yes.
118	21:38:13 <TimStarling> pasting HTML into VE is already good enough to be useful
119	21:38:14 <robla> brion: we support it today, but it's an arms race, isn't it?
120	21:38:17 <brion> benefits of source copy?
121	21:38:18 <TimStarling> I have used it a few times
122	21:38:19 <brion> hehe yep
123	21:39:00 <robla> no one (that I'm aware of) has defined a useful subset of HTML that is safe for copy/paste operations
124	21:39:08 <brion> but so is markdown isn't it?
125	21:39:22 <brion> if we support github's extensions, next we get asked about someone else's extensions
126	21:40:18 <brion> #info question is the HTML copy-paste "arms race" good enough vs markup-specific paste converter tools for markdown etc?
127	21:40:36 <TimStarling> HTML paste is likely to work if the HTML is very simple
128	21:41:00 <TimStarling> for example if you're copying from a github README.md you'd expect it to work
129	21:41:29 <robla> TimStarling: is there a "very simple" subset of HTML we can get browser makers to support?
130	21:41:43 <robla> (for copy/paste purposes)?
131	21: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?
132	21:42:24 <TimStarling> robla: no... but then browsers can't export to markdown either
133	21:42:31 <brion> #link https://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-12
134	21:42:55 <robla> subbu: I think like that could happen
135	21: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.
136	21:44:05 <robla> subbu: what do you mean by "output is more controlled"?
137	21:44:27 <subbu> as in .. VE/CX/Flow etc. don't generate arbitrary html.
138	21:44:39 <robla> ah, got it
139	21: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.
140	21: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
141	21:45:51 <subbu> no, VE does its own handling of copy-pasted HTML .. it doesn't go through parsoid.
142	21:46:20 <brion> fun :D
143	21:46:29 <TimStarling> you mean it cleans up the HTML before it hands it to parsoid for serialization?
144	21:46:41 <subbu> but, we've talked about creating a library for normalization and cleanup.
145	21: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
146	21:47:10 <subbu> TimStarling, as far as i know ... they strip unrecognized / unsupported attributes.
147	21: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
148	21: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
149	21:50:32 <brion> well, there's the html-only world possibility :)
150	21:50:47 <brion> where you'd still have some validation stage
151	21:50:56 <brion> but not a major reparse i guess
152	21:51:14 <brion> (and presumably a stage to handle composition of templates, media etc)
153	21: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.
154	21:52:09 <robla> I think we live in a world where wikitext is sanitized and tries to be safe, and HTML is known unsafe
155	21:52:28 <brion> indeed we'd have "inside html" and "outside html" at the least
156	21:52:32 <subbu> which is also something that needs to happen with a html-only wiki .. sanitization at the very least.
157	21:52:32 <brion> never, EVER mix em :D
158	21:52:44 <robla> there's no "sanitized HTML" spec
159	21:53:09 <subbu> :)
160	21: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
161	21:53:37 <robla> there's the old HTML email spec
162	21:53:58 <robla> (but yeah, that's not really a good alternative)
163	21:54:38 <robla> https://en.wikipedia.org/wiki/HTML_email
164	21: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
165	21: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
166	21:56:15 <brion> i tend to agree
167	21:56:36 <TimStarling> "original markdown" as in http://daringfireball.net/projects/markdown/syntax
168	21:56:45 <TimStarling> which is much simpler than pandoc markdown
169	21:57:28 <robla> commonmark would be the modern simple version, I think
170	21:57:47 <robla> http://commonmark.org/
171	21:57:50 <brion> ok we're getting low on time
172	21:58:09 <brion> any action items to pursue? decisions made?
173	21: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.
174	21:58:21 <stashbot> T127329: Using Parsoid as a wikitext bridge for importing content into wikitext format - https://phabricator.wikimedia.org/T127329
175	21:58:50 <brion> #link https://phabricator.wikimedia.org/T127329 related parsoid bridge for html-import-to-wikitext
176	21:59:19 <Scott_WUaS> Thanks All!
177	21:59:26 <TimStarling> so I'm fairly skeptical about the idea of direct markdown paste as being superior to markdown->html->wikitext
178	21:59:28 <robla> subbu: my understanding is that you're working on RFCs as a goal soon, right?
179	21: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?
180	21:59:50 <brion> yay wikidata -> contenthandler \o/
181	22:00:17 <subbu> robla, rfcs for .. that task i pasted above?
182	22:00:21 <brion> #info tim is skeptical of direct paste; html import seems to serve well
183	22:00:33 <robla> subbu: something related to T112999?
184	22:00:34 <stashbot> T112999: Let MediaWiki operate entirely without wikitext - https://phabricator.wikimedia.org/T112999
185	22:00:43 <brion> #action someone should revise the RfC, probably drop the cut-paste
186	22:00:44 <subbu> ah, cscott territory.
187	22:00:49 <subbu> yes.
188	22:00:58 <brion> #action update T112999 for the ContentHandler era
189	22:00:58 <stashbot> T112999: Let MediaWiki operate entirely without wikitext - https://phabricator.wikimedia.org/T112999
190	22:01:15 <subbu> i'll chat with him about it.
191	22:01:36 <brion> #action subbu will chat with cscott
192	22:01:38 <brion> thanks all!
193	22:01:41 <brion> #endmeeting

• RobLa-WMF updated the event description. (Show Details)Jun 22 2016, 10:38 PM

• RobLa-WMF mentioned this in P3299 ArchCom-RFC-2016W25-irc-E218.txt.Jun 22 2016, 10:41 PM

jayvdb updated the event description. (Show Details)Jul 4 2016, 4:13 AM

• RobLa-WMF mentioned this in T146749: Consider using Phabricator Calendar events to schedule Wikimedia Developer Summit sessions.Oct 6 2016, 5:57 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).

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