[21:05:40] * bd808 looks around for an RfC meeting [21:09:18] crickets... [21:10:03] * Emufarmers watches the tumbleweeds blow past [21:12:55] robla, TimStarling DanielK_WMDE rfc meeting happening today? [21:13:13] robla rescheduled it for half past the hour [21:13:18] ah, ok. [21:14:01] is there a place where this scheduling happens? [21:14:03] bd808, SMalyshev, Emufarmers: ^^^ [21:14:19] SMalyshev: on the event page in phabricator [21:14:24] aha [21:15:11] https://phabricator.wikimedia.org/calendar/query/day/ [21:15:12] but it'S not vey nice to use. it's tricky to find the page for the current meeting from the page for the recurring event https://phabricator.wikimedia.org/E66 [21:15:25] but there should have been a wikitech-l post about the change in time [21:16:04] i keep staring at E66, wondering how i can find the page for the next upcoming incarnation [21:16:22] ah, https://phabricator.wikimedia.org/calendar/query/ShzbHT6BPGCE/ [21:16:23] there is also a google calendar event of course, robla recently recreated it in the engineering calendar [21:16:31] we should have a short url for that. one we can remember [21:16:38] but that is only visible by staff members [21:16:58] and was today's entry in google calendar updated to be half san hour later? [21:17:15] looks like it is, yes [21:20:32] if you want it to show up in your own calendar, you have to add yourself as a guest [21:21:00] oh there's two events there now - one 2pm and one 2:30 pm [21:21:01] which deosn't seem to be possible for mere mortals [21:21:45] SMalyshev: huh :D [21:22:17] ok, I need to clean up my calendar [21:22:20] bd808: really? you don't have an "add guests" link? [21:22:51] SMalyshev: you must have copied the old event [21:22:59] I don't have any links on WMF Engineering one [21:23:00] TimStarling: nope. There is an "Add notification" link but it wont actually save any changes [21:23:05] * robla reads backlog now that he's back to his computer [21:23:41] right, so in sharing settings there's a big list of people who can edit it [21:23:42] looks like the guest of honor is out of class ;) [21:24:23] hi :) [21:24:51] hm... while w ewait... I'm playing with vagrant for the first time -- it's stuck at "Mounting NFS shared folders..." [21:24:53] ideas? [21:25:07] fix your nfs server? [21:25:16] TimStarling: one thing I forgot to do last hour was figure out who is going to do the meetbot thing (I think). I'll go ahead and do it this month (barring objections) [21:25:35] DanielK_WMDE: or run `vagrant config nfs_shares off` [21:25:52] yes, you can do it [21:26:44] * legoktm waves for real now [21:27:34] bd808: thanks, will look into it [21:27:41] bd808: I added you, so you can edit the event now [21:28:00] DanielK_WMDE: you might try hitting enter. I kind of remember some situations where it really wants to promt you for a sudo password but doesn't write anything to the console [21:28:17] ah, good to know [21:28:47] bd808: I'll add you as a guest [21:28:57] TimStarling: already done, thanks [21:30:11] if anyone else wants to be added as a guest to the google calendar event, send me a private message [21:30:32] shameless plug: mw-vagrant using LXC is really fast on debian testing [21:30:43] way way faster than on my mac [21:30:56] starting in 15 seconds... [21:30:57] bd808: do you have a howto on setting it up with LXC? [21:31:01] I've been using bare LXC this week, for java not for mediawiki [21:31:10] bd808: LXC on a mac? [21:31:14] https://github.com/wikimedia/mediawiki-vagrant/blob/master/support/README-lxc.md [21:31:17] #startmeeting T91162 - Shadow namespaces [21:31:17] Meeting started Wed Apr 20 21:31:17 2016 UTC and is due to finish in 60 minutes. The chair is robla. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:31:17] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:31:17] The meeting name has been set to 't91162___shadow_namespaces' [21:31:17] T91162: RFC: Shadow namespaces - https://phabricator.wikimedia.org/T91162 [21:31:54] #topic Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:32:15] hi folks! [21:32:39] hello [21:32:54] I think everyone here is familiar with the shadow namespaces concept, right? [21:33:05] task: T91162 [21:33:05] T91162: RFC: Shadow namespaces - https://phabricator.wikimedia.org/T91162 [21:33:29] #link https://phabricator.wikimedia.org/T91162 [21:33:57] I wrote up a "first steps" section at https://www.mediawiki.org/wiki/Requests_for_comment/Shadow_namespaces#First_steps [21:35:09] And wanted to make sure that sounded reasonable [21:35:36] I'm going to start implementing all of that...now basically. [21:35:59] legoktm: what do you think would be reasonable to get out of this meeting? is it approval time for this, or are we still earlier in the process? [21:36:06] i had a question. why remote action=parse vs. remote action=expandtemplates? i.e. don't titles need to resolved wrt the local wiki? [21:36:32] i meant: links to resources besides the remote resource being accessed [21:37:04] yea, good point. where to links point to? [21:37:04] * robla regrets not filling in the "meeting type" field in https://phabricator.wikimedia.org/E162 [21:37:17] robla: approval for the first steps section, and then discussion of some of the questions in open questions [21:38:11] so I understand this would be including rendered HTML from other wikis? what are the security implications? [21:38:14] subbu: I think the links should point to content on the remote wiki, because that's how the content was authored on that wiki. it's currently what we do for foreignfilerepo, and what we should be doing for globaluserpages except there's a bug in that [21:38:26] Hi [21:39:02] how does this work for templates? ex: {{remote-tpl|link=[[my_local_article]]}}? [21:39:26] legoktm: [Low priority] I'm curious as to your thoughts on whether this approach will also eventually apply to the i18n system (i.e. the magic of the MediaWiki: namespace). [21:39:27] SMalyshev: basically what's outlined at , the remote wiki can't allow raw HTML or anything. The HTML emited by the parser is assumed to be safe to output [21:40:11] subbu: everything would be parsed in the context of the remote wiki, and links would point to the remote wiki [21:40:32] hmm ... need to ponder that. [21:40:59] legoktm: so templates are resolved with respect to remote wiki? [21:41:01] James_F: you mean something like https://www.mediawiki.org/wiki/Extension:MessageCommons ? [21:41:22] phase one is pretty much making it possible to do what GlobalUserPage does on any page. Is that a reasonable summary? [21:41:32] legoktm: Yeah, ish. [21:41:39] that may limit template usage that use context (stupid example: Welcome to {{this page}}, {{user}}) [21:41:40] bd808: GlobalUserPage and ForeignFileRepo*, but yes [21:41:54] legoktm: Plus also all the complications about edit vs. create vs. "over-ride". [21:42:00] subbu: it would be extremely hard to make it work correctly otherwise, i think. [21:42:53] James_F, legoktm: [Low priority] I'm curious about using this approach for the Module namespace. [21:42:54] wouldn't action=expandtemplates done remotely handle {{remote-tpl|link=[[my_local_article]]}} and such? [21:42:54] the applications this would be used for would be global user pages, foreign files, and help pages (https://www.mediawiki.org/wiki/Requests_for_comment/Shadow_namespaces#Applications) [21:43:34] subbu: kind of, but what if the template does a {{#ifexist:}} on "my_local_article"? [21:43:45] subbu: but then you have the same problem in that your local article is remote for the remote wiki, don't you? [21:43:54] right ... [21:44:00] cscott: modules and templates need local parsing, which would be phase 2 [21:44:00] legoktm: global templates? lua modules? [21:44:07] DanielK_WMDE: phase 2! [21:44:08] From a product POV, my main concern is about how we make calling remote templates (and modules) "work" nicely in multi-lingual contexts (or to be more blunt, how do we avoid English imperialism and making non-English speakers not feel excluded/second class/etc.). [21:44:13] legoktm: :D [21:45:22] Er, before we start talking about global templates/modules, can we make a decision on phase 1/"First steps"? [21:45:22] legoktm: with MediaWikiServices in place, we can start thinking about refactoring Parser, so it doesn't rely on global state. But I guess before we can safely parse a page "for" another wiki in the same request, pretty much all of MediaWiki will need to be refactores to not use global state [21:45:37] I have no objections to the first steps [21:45:41] legoktm: Yeah, sorry. [21:45:52] I'm in favour of Phase 1 too. [21:45:53] DanielK_WMDE: Yes. Which is why right now everything is just making cross-wiki API requests [21:46:38] doing things is phases is good because it limits the "what about..." questions and should lead to something that is usefully shippable. [21:46:39] sorry .. i read the rfc in detail for the first time today and so i am having all these basic questions. [21:47:14] legoktm: should be fine for now. not for system messages though (thinking about James_F's question) [21:47:24] what question are we trying to answer here? sounds like "what scope should an included resource have?", but I'm not sure that captures it [21:48:00] legoktm: how about programmatic access to the page source? will that be possible in a transparent way, via a WikiPage or Revision object? [21:48:04] or is it all just show? [21:48:46] * DanielK_WMDE stops asking questions and goes to check the wiki page [21:48:50] robla: "should legoktm begin work on implementing phase 1?" is the question I'm hoping to get answered :) [21:49:00] yes [21:49:19] regarding first step subitem "Start abstracting ForeignFileRepo remote-transcluding code into core to handle other namespaces" [21:49:24] #info question being discussed: should legoktm begin work on implementing phase 1? [21:49:28] DanielK_WMDE: Let's not encourage new code assuming a 1:1 relationship between view and edit modes. :-) [21:50:05] a subtask of that, not mentioned yet, is the fact that CSS comes with the remote description page [21:50:31] abstractly, we are transcluding a bundle of content plus CSS [21:50:46] DanielK_WMDE: by "page source" do you mean wikitext? Since remote parsing doesn't really have a concept of source, I don't think there would be. Things like Title::isKnown() would return true though [21:51:12] #info legoktm is hoping for approval on the first steps section, and then discussion of some of the questions in open questions [21:51:19] legoktm: whetever content there is. wikitext for global templates. loa code for global modules [21:51:23] *lua [21:51:59] well, for global templates, we could also go for html based transclusion. that ties in with last week's rfc [21:52:01] i guess my other question is whether foreign-file-repo, global-user-page, remote-templates are all instances of the same problem ... i.e. full parse of content in remote wikis. [21:52:35] subbu: the way templates work right now, they can't be rendered on the remote system if you want to include them locally [21:52:37] TimStarling: right. And that CSS is loaded outside of ResourceLoader, which is non-ideal. Also RL modules added by parser tags/functions aren't emitted in action=render. GlobalUserPage has some handling of it via action=parse, but that isn't perfect. [21:52:56] DanielK_WMDE, right. [21:53:38] i am mostly trying to wrap my head around remote-parse of transclusions ... [21:53:52] Remote parse of local-to-remote transclusions. [21:54:06] subbu: remote templates (and modules) are a different class of problem, which I think require local parsing. But foreign file repo, global user page, and help pages are all okay with remote parsing [21:54:08] templates obviously can be rendered remotely, that is the existing feature $wgEnableScaryTranscluding [21:55:16] $wgEnableScaryTranscluding also allows local rendering with the RAW option [21:55:24] okay .. so, that fits into how i understood this then. i am happy to ask basic qns. later if you guys want to move along. :) [21:56:08] the one thing we *don't* have is mixed local/remote rendering, e.g. templates coming from one wiki and links from another [21:56:22] right. [21:56:31] but the current proposal is just to refactor the things that do exist [21:56:37] got it. thanks. [21:57:04] #info some questions on how to handle CSS that comes with the remote page; GlobalUserPage has some handling for this but not perfect [21:57:14] Do we have any live questions about the main question? It feels like we have agreement? [21:58:03] I think we can say it is approved and move on to the "open questions" section of the wiki page [21:58:07] #info TimStarling sais that $wgEnableScaryTranscluding already allows remote as well as local parsing of remote templates [21:58:15] https://phabricator.wikimedia.org/diffusion/EGUP/browse/master/GlobalUserPage.body.php;f1c4a384839d28f5fc622fe94e6cc079e2bde25e$67 is GUP's handling of remote modules [21:58:45] #link https://phabricator.wikimedia.org/diffusion/EGUP/browse/master/GlobalUserPage.body.php;f1c4a384839d28f5fc622fe94e6cc079e2bde25e$67 is GUP's handling of remote modules [21:59:16] ok, the first open question I wanted to discuss is actually the last one on https://www.mediawiki.org/wiki/Requests_for_comment/Shadow_namespaces#Open_questions [21:59:26] specifically regarding the opt-out feature GlobalUserPage currently has [21:59:37] * DanielK_WMDE wonders whether Content objects need to know their "home", to provide context to local rendering, and allow rendering against the correct remote [21:59:54] if your page is blank, or you wrap the entire thing in tags, then we pretend your user page doesn't exist [22:00:08] legoktm: Except for MW: where we use '-', magically. [22:00:19] right [22:00:20] could have a double-underscore tag instead [22:00:23] It'd be nice to come up with a consistent system. [22:00:35] TimStarling: +1 [22:00:38] __PLEASENOINHERIT__ [22:00:53] * robla plans to use the #agreed command on " I think we can say it is approved and move on to the "open questions" section of the wiki page" [22:01:21] James_F: __OHGODPLEASENOINHERIT__ [22:01:27] TimStarling: the double underscore would set a page prop that we could query for? I like that [22:01:35] +1 [22:01:35] #agreed I think we can say it is approved and move on to the "open questions" section of the wiki page [22:01:37] yes [22:03:09] how would that work for non-wikitext content? [22:03:24] ok, another question that came up recently was how we could allow local wikis to append/augment remote content, specifically in the use case of help pages: https://www.mediawiki.org/wiki/Topic:T2f1remrtx6et2ba [22:03:40] do we need to define a magic word syntax for other formats? [22:03:42] Do we want to do that? [22:04:13] DanielK_WMDE: the implementation would define a different way to set the page property in the ParserOutput object? [22:04:22] DanielK_WMDE: The __FOO__ system (and e.g. #REDIRECTs) needs replacing with other stuff for general content types anyway. Let's not divert this discussion? [22:04:22] #info question discussed: how we could allow local wikis to append/augment remote content, specifically in the use case of help pages: https://www.mediawiki.org/wiki/Topic:T2f1remrtx6et2ba [22:04:52] #info Tim suggested replacing the current GUP opt-out sytem with a double underscore tag that sets a page property and can be queried for [22:05:53] legoktm: quiddity [22:05:57] grr [22:06:07] quiddity's question is very complex [22:06:18] legoktm: yea, we need to come up with a mechanism for that i guess [22:06:28] it would be some sort of merge operation between remote and local content [22:06:57] and subject to all the problems of keeping a local patch against a remote source [22:07:04] needs a better user story or UI description I guess [22:07:46] James_F, that at least, was the solution that occurred to me, regarding how to prevent constant forking/drift/redundancy/replication. How else do we get improvements to https://en.wikipedia.org/wiki/Help:Link into https://meta.wikimedia.org/wiki/Help:Link whilst still allowing Enwiki (etc etc etc) to keep their local page-hatnotes, and section-hatnotes, and section-addendums. [22:07:47] My strong recommendation would be to not even try to support that use case. [22:08:30] quiddity: "Don't". [22:09:07] Nod. I just wanted to ensure it is considered, as much as feasible. [22:09:08] Going out of our way to make the system worse (slower, more broken, more complex) just so that users can avoid working with each other is not "better" for users [22:10:03] doing it "right" probably requires inventing a human-level AI [22:10:16] legoktm: regarding the low number of users that use opt-out on meta... when comparing feature usage numbers, i think it makes sense to scale the usage by the number of edits/actions the user did recently. across all projects, in this case. [22:11:02] some features are only used by a few power users, but may be important to, well, empower them to be power-users. [22:11:06] i think quiddity's use case verges on a separate RFC for "better supporting fork/join mechanisms" [22:11:15] That's... not quite the way I'd put it, James_F. I want *increase* the number of editors from the large wikis, who work on improving the main/default documentation, so that all languages can benefit. [22:11:20] i don't think we're helped by trying to make legoktm solve all the world's problems at once [22:11:23] cscott: Indeed. There's a use-case. [22:11:40] cscott: agreed [22:11:41] DanielK_WMDE: right. [22:12:02] * quiddity nods. [22:12:06] this is a common issue in RfC meetings I think. The "what about.." scope expansion [22:12:10] without getting too far on a soapbox, i'll note that git shows that we can maintain completely separate copies of en:Help:Link and :meta:Help:Link and still provide good tools for merging changes between them. [22:12:18] Yup. [22:12:22] we don't need to make them somehow be exactly the same entry in a database somewhere [22:12:40] next question? [22:13:01] Namespacing? [22:13:04] Does legoktm need anything else? Support/ideas/help from any of us? [22:13:34] * cscott turns into a pumpkin [22:13:41] Those are all the questions I had for phase 1 stuff, the remaining questions are about phase 2/local parsing stuff [22:13:54] Yeah, namespacing. "Namespacing: should we have a "Global templates" namespace or should it be transparent like InstantCommons?" [22:13:55] #info i think quiddity's use case verges on a separate RFC for "better supporting fork/join mechanisms" [22:14:13] legoktm: Transparent, I think. [22:14:16] * robla probably should have used the #idea command [22:14:30] James_F: Not at the moment, but I will definitely ask when I need it [22:14:30] legoktm: a separate namespace is basically an opt-in mechanism [22:14:31] I prefer explicit global namespace instead of implicit/transparent fallback which can have unintentional side-effects when, for example, a previous use of global template is shadowed by a newly created local template of the same name. [22:14:35] legoktm: there probably needs to be a way to know where template comes from [22:14:43] #info Use case of "Centralized, but locally-appendable, documentation pages" is out of scope [22:15:02] whether it is local or global [22:15:07] If we're going to have transparent fallbacks for "some" namespaces and not for others I think that's a worse, not better, outcome. [22:15:10] but that can be done with transparent too [22:15:14] (Some == File, User, ???) [22:15:21] SMalyshev: why does the user need to know where the template comes from? [22:15:41] So they can fix it, I guess? [22:15:57] James_F, legoktm but we resolved that global templates are not the same as GUP, remote-file-repos, etc? [22:16:00] the tabs solution would handle that right? Adding info on the imported page that points back tot he origin? [22:16:12] I agree with subbu [22:16:16] legoktm: looking at GUO I see some things are still resolved in origin's context [22:16:17] So that they don't check locally first, but instead go directly to the actual destination. [22:17:05] legoktm: s/GUO/GUP/ [22:17:18] SMalyshev: uh, which things? [22:17:33] legoktm: https://www.mediawiki.org/wiki/Help:Extension:GlobalUserPage#Where_content_comes_from <- these? [22:17:36] I'm not sure the "let's do lots of tabs" option is a great one for users – see e.g. https://www.mediawiki.org/wiki/File:Upload-classify.png with "Read" | "View on Commons" | "Add local description". [22:18:06] SMalyshev: yeah, the "Wikilinks are relative, so they'll point to the local wiki" is a bug, https://phabricator.wikimedia.org/T89916 [22:18:26] legoktm: also, I'm not sure how permissions would work - what if you can edit local wiki but not central wiki? [22:18:33] uh... btw, how do section edit links work with global templates? those are injected in a magic way on the fly... [22:19:16] SMalyshev: you can't edit the template then? [22:19:22] DanielK_WMDE: I have no idea :P [22:19:25] I guess we forked here. The namespace question is about whether asking for [[Template:Foo]] gets you a template from a remote or if you have to say [[Global template:FOO]] ? [22:19:38] * robla plans to use #endmeeting very close to 22:30 UTC [22:19:42] Yeah. [22:19:43] legoktm: but you should be able to understand why. I.e. it should tell you "you can't edit it because it's on CentralWiki" [22:20:23] SMalyshev: wouldn't a notice that says "This template is from CentralWiki blah blah blah" like the InstantCommons/GUP notice? [22:20:24] legoktm, TimStarling, subbu: could [[Template:Foo]] be a redirect to [[Global template:Foo]]? [22:20:33] yes [22:20:41] works for me then [22:20:43] legoktm: that's one way of knowing where the template comes from :) [22:21:27] that way when you edit [[Template:Foo]] and see that it is a redirect, you would know that it is used locally and be alerted to what editing it will do [22:21:40] #idea legoktm, TimStarling, subbu: could [[Template:Foo]] be a redirect to [[Global template:Foo]]? [22:21:47] what TimStarling said [22:22:10] legoktm: another thing - suppose, you have local Template:Foo and global Template:Foo. And you want to delete the local one. So you are attempting to delete it, but unknown to you, some other admin just deleted local one. So oyud instead delete a global one. Wouldn't you want to know which one it is really? [22:22:35] or, alternatively, we won't allow both local and global have the same name? [22:22:48] I don't think you can delete globals from the foreign wiki [22:22:55] uh ^ yeah [22:22:56] or rather should not be able to [22:23:34] User rights on the local wiki don't extend across the foreign access api [22:23:35] SMalyshev, i don't think global templates => you have full access to the resource as if on a local wiki .. it is a read-only copied resource. [22:23:41] bd808: but then if you have no redirect (which seems like a viable solution) then looking at Template:Foo if it;s global it would look like local but behave differently [22:24:08] so I think there should be explicit mark in UI to specify it's a copy, not a real thing [22:24:10] sure, just like instantcommons does now [22:24:32] I think transparency is less complex. [22:24:34] (and maybe in non-UI too so that you could make proper UI in apps) [22:24:58] James_F: it is. but is it less confusing? i'm undecided... [22:25:04] attribution of the foreign source seems reasonable and necessary [22:25:22] bd808: that's what I think too [22:25:27] bd808: good point: it's even required by the license. [22:25:30] DanielK_WMDE: Less complex/confusing for users given the existing transparent things we already do, yes. [22:25:42] DanielK_WMDE: Depends on the wiki. :-) But yes. [22:25:51] I'm not hung up on how that attribution is surfaced in the UI [22:25:55] doesn't have to be different namespace, but I think has to be *something* [22:25:58] i think templates are different kind of resource compared to user pages (localized effects to one user) or images (simple uses) and are used more pervasively all over. [22:25:59] "we'll figure it out" [22:26:00] we're down to the last 5 minutes of the meeting time. we can continue the conversation on #wikimedia-tech at 22:30 UTC [22:26:05] so, i think explicit namespace is better. [22:26:18] #idea attribution of the foreign source seems reasonable and necessary [22:26:45] I think transparently including templates would give you an interface where there are unintended consequences of user actions [22:26:50] #info TimStarling and subbu favor an explicate foreign template namespace [22:27:11] typo :) [22:27:19] that's why I don't think it is simpler for users [22:27:20] heh [22:27:25] it is simpler until it goes horribly wrong [22:27:42] TimStarling: exactly [22:27:44] the namespace manes sense as long as redirects can "hide" it from most users [22:28:05] * robla thinks several programming languages should have that slogan ;-) [22:28:18] "it is simpler until it goes horribly wrong" [22:29:18] sorry, my internet kind of died [22:29:25] are we going to end on my bad joke note? ;-) [22:29:37] :P [22:29:46] thanks for the discussion and input everyone [22:29:53] duploktm: I think we're just about ready to wrap things up. 30 second warning [22:30:10] 10 seconds.... [22:30:24] great meeting, thanks everyone! [22:30:29] #endmeeting [22:30:30] Meeting ended Wed Apr 20 22:30:29 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:30:30] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-04-20-21.31.html [22:30:30] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-04-20-21.31.txt [22:30:30] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-04-20-21.31.wiki [22:30:30] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-04-20-21.31.log.html [22:30:41] \o/ [22:30:54] right on time [22:31:10] -_- ...zzzzZZZZZ [22:31:15] Bye Daniel. [22:31:25] * DanielK_WMDE waves [22:31:34] thanks for staying up DanielK_WMDE ! [22:31:54] $time_approprate_greeting everyone else! [22:32:23] er...make that $time_appropriate_farewell [22:42:56] Bye Daniel [22:46:02] Bye All and thank you