[21:01:20] #startmeeting RFC meeting [21:01:20] Meeting started Wed Oct 21 21:01:20 2015 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:01:20] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:01:21] The meeting name has been set to 'rfc_meeting' [21:01:37] hello [21:01:40] good morning, tim. [21:01:49] hello [21:01:54] #topic RFC: Hygienic template arguments | 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/ [21:02:23] i did s/hygenic/heredoc/ in the rfc, and switched the heredoc arguments to being after any positional arguments, instead of before; that matches what we discussed at the parsing team meeting. [21:02:40] #topic RFC: Heredoc template arguments | 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/ [21:02:44] just fyi, if folks read it before. [21:03:01] is there a link? :) [21:03:10] https://phabricator.wikimedia.org/T114432 [21:03:17] ty [21:03:27] #info https://phabricator.wikimedia.org/T114432 [21:03:51] there's also a link at https://phabricator.wikimedia.org/E80 if you're coming from there. [21:04:17] so what do we need out of this meeting? [21:04:58] approval? [21:05:44] after looking at the RFC, I am still not sure how common or desirable moving large bits of content into templates is [21:06:06] little bikeshedding: usually {{something means template named "something". Can we keep it, i.e. make it something like: {{Table|class="shiny"|<<}} Hello World {{>> Table}}? [21:06:19] or would it conflict with existing usage? [21:06:49] that's an interesting proposal [21:07:24] cscott: do you know of any real-world examples of use cases? [21:07:35] SMalyshev: from the parser standpoint, it's nice to be able to identify the form of the argument right away, instead of having to parse the arguments looking for << [21:08:08] SMalyshev: it also introduces asymmetry with the close-template form. but on the + side, it helps indicate exactly where you want the heredoc argument to go. [21:08:37] cscott: yes... just putting it out there to consider :) [21:08:38] SMalyshev: and allows for {{Table|class=<<|content=<<}} and similar things. [21:08:44] << as an argument means that << is special in plain text, whereas the proposal only makes it special in template names [21:09:03] ah, right. that is a good point. [21:09:23] {{<< is safe because < is not legal in template names. [21:09:37] similarly for the {{>> sequence in the closing tag. [21:09:41] ah, ok [21:11:03] TimStarling: usage in tables (infoboxes, navboxes, etc) would be most appropriate for this new form, since that's where people usually run into trouble with special characters. [21:12:04] but the RFC includes a usage for brion's hypothetical non-point citations as well [21:12:09] infoboxes and navboxes are some of the use cases we were considering widgets for as well [21:12:26] in order to improve editing and re-styling of the content [21:12:29] and in general it is expected to be a useful tool to allow rewrite of templates into a balanced form that VE can edit. [21:13:02] for templates we'd need named args but I see in the examples all plaintext agrs are positional... [21:13:13] the actual {{Infobox}} template on enwiki is scribunto code, so i don't want to claim that infoboxes are the target here. [21:13:22] anything that requires a {{start-element-template}} ... {{row/list/individual-item-template}} .. {{end-element-template}} .. would benefit from this form since this sets up a syntactic DOM structure. [21:13:33] in my experience, the biggest user would be the plethora of table-related templates. [21:13:52] on enwiki now we have Module:Navbox and Module:Infobox [21:13:56] subbu: how will this work for old content? [21:13:59] yeah, what subbu said. ;) [21:14:13] that seems to be the crux of any balancing solution [21:14:16] here is a navbox implementation: https://en.wikipedia.org/w/index.php?title=Template:Cities_of_Australia&action=edit [21:14:34] gwicke: it's not transparent, it's a tool for editors. evangelism is still required. [21:14:56] (that would be https://phabricator.wikimedia.org/T114444) [21:14:57] semantics won't change for old content. we have existing logic for identifying them in code. [21:15:06] s/code/parsoid code/ [21:15:37] {{start-element-template}} and {{end-element-template}} are replaced by {{>>element-template}}, which can initially expand to something like {{start-element-template}}{{{1}}}{{end-element-template}}, and then the use sites are migrated over time. [21:15:39] so, basically you are positioning this as an alternative to the long-discussed or tags [21:15:52] gwicke: no, it's not really related at all. [21:16:06] gwicke: the / is "hygenic templates" (or something like that) [21:16:10] cscott: is it only for positional args? [21:16:21] we renames this RFC specifically because the two things were getting confused for each other. [21:16:23] cscott: I understood subbu that way, at least [21:16:26] gwicke, not related, but potentially a benefit that could be leveraged. [21:17:03] it helps write balanced templates, but it's not directly related to enforcing balance or taking advantage of balance. [21:17:04] it sounds like we need a general solution anyway though, if only for old content [21:17:40] something that works with existing wrapper templates [21:17:55] let me put it this way: dom-balancing is an nice side-benefit of this approach. but, that is not what this is targeting. [21:17:58] the template balancing proposal is https://phabricator.wikimedia.org/T114445, but I don't think the phab ticket has been updated with our latest discussions. [21:18:33] (my kind of preference is to slowly shovel all these sorts of horrible constructs out of markup and into structured data + a simple reference to the template/module that generates the layout from them...) [21:18:43] i'd say, "it helps when writing balanced templates". [21:19:17] yeah, my preference is to move towards structured data + widgets as well [21:19:32] so that navbox I linked to, it does have quite a lot of wikitext in each argument [21:20:07] but the wikitext is in several named arguments: list1, list2, list3, so it is not ideal for this proposed syntax [21:20:57] if folks remember my wikimania talk, there are a bunch of obscure escaping rules for arguments in templates which can trip people up. this is an attempt at providing a syntax with fewer sharp edges, as a way to improve the lives of wikitext authors. [21:21:22] it's not intended to replace all uses of the old template syntax. if there are lots of arguments, or lots of optional named arguments, etc, then this is probably not the right thing. [21:21:51] but the simple "include a chunk of wikitext" cases are pretty frequent in practice, and a barrier to implementing some of the things people would like to do with templates. [21:22:04] I worry that removing sharp edges would encourage *more* use of templates, which in turn isn't necessarily helping the editing experience, especially in VE. [21:22:05] like brion's "let's mark the exact range of text supported by a citation" proposal. [21:22:35] Templates shouldn't be a problem if they are well balanced and have good TemplateData describing them. [21:22:54] gwicke, that seems like a roundabout way of deprecating bad usage of templating though. [21:24:02] TimStarling: the Cities of Australia template is actually mostly a long collection of "group1"/"list1"/"group2"/"list2"/.. arguments. [21:24:12] TimStarling: that might actually work relatively nicely with this new syntax. [21:24:21] we need to be mindful which kind of content we encourage, and which we discourage [21:24:25] cscott: and that is the general format used by {{Navbox}} on enwiki [21:25:17] {{<>Navbox}} [21:25:31] with newlines between the groups, of course, i just put them on one line for IRC. [21:25:47] gwicke, I think removing sharp edges is not a bad thing. This is not meant to solve all templating problems. Widgets + data-driven templates, well-balanced templates, etc. are all needed. None of these individual will fix everything. [21:26:23] subbu: We'd probably see more use of wrapper templates to implement multi-column layouts & the like. We already have those as start / end templates, and they make editing those articles a pain. [21:27:10] VE can invoke itself recursively, so that shouldn't really be a problem. [21:27:38] If you make it easier to wrap entire pages in templates, people will probably start to use that capability. [21:27:39] ProofreadPage also wants a VE instance bounded by a certain region of the page, presumably you could extend TemplateData to allow editing these templates in-place. [21:28:06] gwicke: well, they already are. [21:28:20] here is an example of begin/end templates which are a simpler match to this syntax: https://en.wikipedia.org/w/index.php?title=American_Civil_War&action=edit§ion=47 [21:28:25] the large table pages have {{tablestart}} at the top and {{tableend}} at the bottom, making the whole page template-affected. [21:29:07] the difference is that this gives us a path toward allowing reasonable editing of such content. [21:29:15] and that example is not metadata, right? [21:29:29] it is inherently part of the article [21:29:30] (1) I think templating as a technique is not going away. (2) We should fix problems with templating with a bunch of techniques (3) I would like to see solutions evaluation along the lines of (a) does it improve wikitext editing (b) does it improve visual editing (c) how does it improve readability, etc. [21:29:36] *evaluated [21:29:45] American Civil War is a good example, thanks. [21:29:58] subbu: agreed, there needs to be an evaluation of the impact on all those areas [21:30:22] especially relative to other directions we could choose to move into [21:30:32] i don't think this is a zero-sum game. [21:30:37] what cscott said [21:30:54] every bit of new syntax has a very high cost, as it will need to be supported forever [21:31:04] i don't think that's the case, either. [21:31:14] i think our team's mission is (in part) to migrate wikitext. [21:31:15] so we need to be very deliberate about what we introduce [21:32:10] here's another use of col-begin that is pretty integral to the article text: https://en.wikipedia.org/w/index.php?title=Lord%27s_Prayer&action=edit [21:32:41] it is side-by-side analysis of versions of a text [21:32:51] gwicke, agreed about being deliberate about what we introduce and new syntax needing to be supported forever (or migration plans introduced). [21:34:43] it seems that we need a solid solution for existing content in any case [21:35:32] try VE of [[Lord's Prayer]], it is a good effort, but not ideal [21:35:50] it would be good to a list of concerns that need to be addressed. [21:36:01] yeah, something like switching to embedded VE based on the start template would be nice [21:36:27] it already has a transclusion wrapper around the whole column section, you can't put your caret in the middle of the text [21:37:00] changing that is hard, though, as templates can massage their parameters in random ways [21:37:18] which is partly why widgets are attractive [21:37:40] they provide more control about the relation between inputs and outputs, which can enable things like inline editing [21:37:42] gwicke, I think the argument is that with this new syntax, for a lot of use cases, a recursive invocation of VE enables simpler editing. [21:38:00] yeah, as it is, there is no templatedata for the contents [21:38:07] and VE shows the contents as plain wikitext [21:38:17] We're working on that. :-) [21:38:29] if you introduce a two-column template which takes the columns as arguments, then you can have templatedata for the contents [21:38:29] and widgets will not solve all the myriad use cases. widgets are a solution for some use cases, not the solution that covers all these kinds of templating use cases. [21:38:41] subbu: it doesn't seem to be clear that the syntax would actually change much about the problem [21:38:44] i am not convinced there is a magic bullet. [21:39:01] and you would presumably be able to edit the arguments in HTML mode [21:39:11] gwicke, it can eliminate the use of 5 templates and enable it to be 1 template for one. [21:39:33] TimStarling: right. and with a little work and some templatedata hints you might even be able to convince VE to create its recursive editor in the same layout box used for the original content. [21:39:40] multi-template-usage is hard to support editing for. [21:39:45] single-tempate-usage is more doable. [21:39:45] subbu: for the multi-column case? [21:40:17] it seems that you need to at least mark up the columns somehow [21:40:59] to me it looks like it can, but since I am handwaving, one of us needs to play with that specific usage there to see what gets in the way. [21:41:39] James_F: do you have any comment on the proposal in general? [21:41:54] The multicolumn case is a single template which emits

...arg1...

..arg2...

[21:42:07] and then VE is invoked recursively to edit ...arg1... in a visual fashion. [21:42:12] alternative with tag extension syntax: Some contentsome other content [21:42:44] this would actually be easier to re-style for mobile [21:42:54] so an alternative proposal would be to allow templates to be invoked using tag syntax. [21:43:12] so a template named foo could be invoked either as {{foo}} or as .... [21:43:12] , [21:43:26] one idea is to provide widgets for common functionality [21:43:42] like multi-column layouts or data tables [21:43:44] gwicke: again, i think widgets are orthogonal. [21:43:57] TimStarling: I'm agnostic. [21:44:11] cscott: they are trying to address many of the same issues [21:44:15] so I think they are related [21:44:31] cscott: in T114432 description "the contents... are passed as (WLOG) the last positional argument". What's "WLOG"? [21:44:40] "without loss of generality" [21:44:40] without loss of generality [21:44:53] it just means that its not an essential part of the proposal, we could do it the other way round if you prefer [21:45:06] and in fact the original proposal had the arguments passed as the first positional arguments instead of the last [21:45:22] TimStarling convinced me it was a little more intuitive as the last arguments instead of the first. [21:45:52] cscott: So with {{<>foo}}, how would that work for VE? I imagine it can't edit that very well? [21:45:56] because that's the lexical order, the order it appears in the input [21:46:00] So it's a way to not have to escape one of the parameters (and only one) [21:46:17] I missed the context, so sorry if I'm missing the higher level goal [21:46:21] Krinkle: yes, the unbalanced case is handled by https://phabricator.wikimedia.org/T114445 , not by this proposal. [21:46:45] but this does let you write balanced templates a little easier than at present. they are complementary, but not strictly related. [21:47:00] cscott: But do you imagine in the end it can be edited in VE? Otherwise it seems like shuffling around with lots of migration but very little end user improvement. [21:47:02] cscott templates as balanced tags feels more natural and no new syntax, but it seems it would overlap with parser tags. [21:47:17] you have less unbalanced templates with this proposal if you migrate e.g. col-start/col-end to a single column template [21:47:26] Krinkle: there's https://phabricator.wikimedia.org/T114445 to enforce balance. [21:47:56] in the absence of enforced balanced, this syntax lets you write "well-behaved templates" that will be editable in VE assuming that the content inside is not crazy. [21:48:05] so it helps in the common case all by itself. [21:48:06] spagewmf: it would simply *be* tag extensions [21:48:11] whether you have opt-in balancing or opt-out balancing, {{col-start}} is obviously not going to be balanced [21:48:26] so it doesn't help [21:48:26] T114445 lets the template author say "please don't let my users do anything crazy inside me", and enforce it. [21:48:27] or could be, I should say [21:48:33] I'm not sure I see how this would reduce unbalanced content. Should users start in foo-start and in foo-end? I don't think you want that. You'll still have unbalanced wikitext as a parameter that is presumably not editable. [21:48:41] if you migrate to a single wrapper template, then it can opt in to balancing [21:49:13] right, what TimStarling said. [21:49:37] This helps Parsoid identify which portions are unbalanced (instead of its inferred detection now), and changes from unbalanced foo-start and foo-end to unbalanced foo. [21:49:42] enforcing balancing my itself isn't going to help if you content uses {{col-start}}. there's no way to opt-in to balancing that template without breaking the output. [21:49:51] #info if you migrate to start and end templates to a single wrapper template using this proposal, then it can opt in to balancing (T114445) [21:50:07] Krinkle: no, it offers no hints to parsoid. that's T11445. again. [21:50:20] this rfc is purely for humans writing wikitext content. [21:50:22] how would this opt-in work for old content? [21:50:37] gwicke, what would help old content anyway? [21:50:46] would it simply break? [21:51:01] cscott: Given both RFCs, would we be in a situation where you can have a template foo that takes unbalanced wikitext as hygienic parameater and have it editable in VE? [21:51:02] but, looks like there is more clarity required with this RFC. [21:51:13] towards that, getting a list of concerns and questions would be a useful outcome of this discussion. [21:51:16] we'll have a wrap-up period starting at 55 minutes past the hour [21:51:30] gwicke, why would it break? [21:51:44] Krinkle: yes. but what you described is actually just T114445. "a template which takes unbalanced wikitext as [...] parameter and have it editable in VE" [21:51:51] subbu: if you enforce balancing for old uses of a template, then it might break uses in old revisions [21:51:59] cscott: editable as nodes, not as raw wikitext (of course) [21:52:06] gwicke, but, this is new syntax. [21:52:14] so, i am confused. [21:52:26] oh, so all of those templates would be in a separate namespace? [21:52:29] I'm suspicious about how that would work. Without that part, it's just a very roundabout way to get rid of some parsoid technical debt, which iimho wouldn't be worth it. [21:53:00] Krinkle: again, this RFC is almost completely unrelated to parsoid. [21:53:12] subbu: basically, you are saying that you would never convert an existing multi-column template into the new syntax & opt-in to balancing [21:53:15] right, it would require some templates to be forked. [21:53:28] you cannot just edit the templates as is. [21:54:08] this brings up the bigger question of opt-in vs. opt-out as well [21:54:09] I like the idea of being able to pass unescaped wikitext as a parameter to a start/end template so that foo-start/end style templates no longer need to be split up but can be one coherent template. [21:54:14] the proposal assumes opt-in [21:54:15] new template {{some-template}} == {{some-template-start}}{{{1}}}{{some-template-end}} [21:54:31] and then eventually uses of {{some-template-start}} & friends can be migrated to {{>>some-template}} [21:54:49] Yeah, existing content won't break. Users can create a new wrapper template and slowly (or quickly) migrate towards that as they see fit. [21:55:09] yup [21:55:22] ok, let's wrap up [21:55:26] cscott, AIUI editors can use this heredoc syntax with any template. a) can templates detect it? b) can anything break? [21:55:51] please write only summaries (with #info) and action items (with #action) [21:55:53] * subbu will read up Krinkle's quetions after. [21:56:35] spagewmf: currently there's no explicit way to detect that heredoc syntax is being used. that could be added, if there's a good reason. [21:56:39] #action RFC needs additional clarification to address some of the questions here [21:57:00] #info at least gwicke is hesitant to introduce new syntax without a clear cost / benefit analysis, considering alternative solutions and impact on wikitext / visual editing and reading [21:57:10] spagewmf: the only one i can think of is namespace related -- you've decided that {{foobar}} is indeed the perfect name for your template, and you don't want to fork off {{foobar-prime}} with some slightly different argument ordering to accomodate heredocs. [21:57:15] #info my kind of preference is to slowly shovel all these sorts of horrible constructs out of markup and into structured data + a simple reference to the template/module that generates the layout from them... [21:57:26] cscott, can you focus for a bit on adding #info and #action items if any? [21:58:21] spagewmf: wrt (b) can anything break -- we believe the answer is no, since {{<< isn't valid markup right now. but one of the purposes of the RFC discussion is to surface any issues like these that we haven't thought of. [21:58:23] #info James_F is agnostic about this proposal (not sure if that is a personal position or from a VE perspective) [21:58:32] Ha. [21:58:36] :) [21:58:38] #info discussion brought up general questions about the longer-term template balancing / DOM scoping strategy [21:58:44] I mostly meant "I haven't spent the time to have a position". [21:58:49] subbu: what does "RFC needs additional clarification to address some of the questions here" mean? [21:59:03] subbu: it would be more helpful to have specific topics which should be addressed. [21:59:05] #action explain the benefits in terms of VE and T114445 [21:59:26] (I mean on the RFC, since that was a point of confusion) [21:59:33] yeah, that's good. [21:59:42] cscott, yes, i think part of the action work would be to identify that list of questions and concerns from this irc discussion. [21:59:59] i was just worried that i would read "address some of the questions here" later and have no idea what specific questions were meant. [22:00:57] so if folks have specific areas they were confused about when reading the RFC, #info/#action items would be appreciated. [22:01:08] #info I think we should consider structured data + widgets using existing tag extension syntax as an alternative [22:01:22] in general there is not consensus [22:01:30] ya [22:01:30] #action decide if "allow templates to be invoked using tag syntax" is dead or worth pursuing [22:02:01] ok, thanks everyone [22:02:20] next week we will probably have T384, if Daniel is available [22:02:24] thanks, TimStarling. [22:02:38] #endmeeting [22:02:38] Meeting ended Wed Oct 21 22:02:38 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:02:38] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-10-21-21.01.html [22:02:38] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-10-21-21.01.txt [22:02:38] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-10-21-21.01.wiki [22:02:39] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-10-21-21.01.log.html [22:03:09] TimStarling: also gwicke and ottomata and others will be discussing the EventBus tomorrow, which also has an RFC [22:03:20] https://phabricator.wikimedia.org/T114443 [22:03:31] and my apologies to Krinkle; i probably need to pay closer attention to describing the relationship (or lack thereof) to T114445 and parsoid, instead of just assuming that if i don't mention them folks will understand they are not related. [22:03:33] oh, there are multiple rfc meetings pre week now? [22:03:39] *per [22:04:06] the eventbus thing is a regular meeting; let me know if you'd like to join the hangout [22:04:18] subbu: not quite, it's just an open meeting on https://phabricator.wikimedia.org/T114443 whose official RFC discussion has been postponed a few times [22:04:22] well, we did have two meetings a couple of weeks ago, with the email login RFC [22:04:36] spagewmf, ah, ok. [22:05:10] but yes, this is not really an RFC meeting [22:07:15] https://phabricator.wikimedia.org/T114443#1744036 [22:07:54] teams can put the "#MediaWiki-RfCs" tag on tasks they're going to do regardless; it'll be fun when the RFC process rejects a work task :-) [22:09:09] maybe we should separate RFD from RFC? [22:09:26] as in 'request for decision' vs. 'request for comments' [22:15:56] Krinkle, to answer your questions .. from my understanding .. in the multi-template-dom-structure senarios, what is going on is that the core content of the dom structure (list, table) comes as wikitext args whereas the other templates provide the outer scaffolding. [22:16:27] so, when converted to a single-template case, the args will continue to be balanced args .. and can be edited easily via recursive VE invocation. [22:17:11] *balanced dom content [22:17:20] gwicke: RFD/RFC seems too subtle a distinction. #MediaWiki-RfCs means ArchCom looks at your task, meanwhile reality is patches in gerrit and someone's +2 is the Decider. [22:18:45] subbu: Regular arguments yes, but in the case of foo-start/end where the middle sandwich is part of a table, then I imagine we won't be able to present the table cells as editable? [22:19:30] not directly no. only as a recursive invocation of args that is presented as html (this is the html for template args scenario) [22:20:08] spagewmf: I meant it more as in "we should encourage wider discussion of ideas / WIP" [22:20:39] common practice is to simply do stuff, without writing an RFC or soliciting wider input [22:21:18] gwicke: maybe. there's already the #Architecture tag which some people use as a heads-up. [22:24:43] yeah