Page MenuHomePhabricator
Paste P2935

IRC transcript from Shadow namespaces ArchCom-RFC meeting - 2016-04-20
ActivePublic
Actions

Authored by • RobLa-WMF on Apr 20 2016, 10:38 PM.
Project Tags
None
Referenced Files
F3900626: IRC transcript from Shadow namespaces ArchCom-RFC meeting - 2016-04-20
Apr 20 2016, 10:38 PM
Subscribers
None
21:31:17 <robla> #startmeeting T91162 - Shadow namespaces
21:31:17 <wm-labs-meetbot> 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 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:31:17 <wm-labs-meetbot> The meeting name has been set to 't91162___shadow_namespaces'
21:31:17 <stashbot> T91162: RFC: Shadow namespaces - https://phabricator.wikimedia.org/T91162
21:31:54 <robla> #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 <robla> hi folks!
21:32:38 <legoktm> hello
21:32:54 <legoktm> I think everyone here is familiar with the shadow namespaces concept, right?
21:33:05 <robla> task: T91162
21:33:05 <stashbot> T91162: RFC: Shadow namespaces - https://phabricator.wikimedia.org/T91162
21:33:29 <robla> #link https://phabricator.wikimedia.org/T91162
21:33:57 <legoktm> I wrote up a "first steps" section at https://www.mediawiki.org/wiki/Requests_for_comment/Shadow_namespaces#First_steps
21:35:09 <legoktm> And wanted to make sure that sounded reasonable
21:35:36 <legoktm> I'm going to start implementing all of that...now basically.
21:35:59 <robla> 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 <subbu> 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 <subbu> i meant: links to resources besides the remote resource being accessed
21:37:04 <DanielK_WMDE> 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 <legoktm> robla: approval for the first steps section, and then discussion of some of the questions in open questions
21:38:11 <SMalyshev> so I understand this would be including rendered HTML from other wikis? what are the security implications?
21:38:14 <legoktm> 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 <Scott__WUaS> Hi
21:39:02 <subbu> how does this work for templates? ex: {{remote-tpl|link=[[my_local_article]]}}?
21:39:26 <James_F> 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 <legoktm> SMalyshev: basically what's outlined at <https://www.mediawiki.org/wiki/Extension:GlobalUserPage#Caveats>, 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 <legoktm> subbu: everything would be parsed in the context of the remote wiki, and links would point to the remote wiki
21:40:32 <subbu> hmm ... need to ponder that.
21:40:59 <SMalyshev> legoktm: so templates are resolved with respect to remote wiki?
21:41:01 <legoktm> James_F: you mean something like https://www.mediawiki.org/wiki/Extension:MessageCommons ?
21:41:22 <bd808> phase one is pretty much making it possible to do what GlobalUserPage does on any page. Is that a reasonable summary?
21:41:32 <James_F> legoktm: Yeah, ish.
21:41:39 <SMalyshev> that may limit template usage that use context (stupid example: Welcome to {{this page}}, {{user}})
21:41:40 <legoktm> bd808: GlobalUserPage and ForeignFileRepo*, but yes
21:41:54 <James_F> legoktm: Plus also all the complications about edit vs. create vs. "over-ride".
21:42:00 <DanielK_WMDE> subbu: it would be extremely hard to make it work correctly otherwise, i think.
21:42:53 <cscott> James_F, legoktm: [Low priority] I'm curious about using this approach for the Module namespace.
21:42:54 <subbu> wouldn't action=expandtemplates done remotely handle {{remote-tpl|link=[[my_local_article]]}} and such?
21:42:54 <legoktm> 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 <legoktm> subbu: kind of, but what if the template does a {{#ifexist:}} on "my_local_article"?
21:43:45 <mobrovac> 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 <subbu> right ...
21:44:00 <legoktm> cscott: modules and templates need local parsing, which would be phase 2
21:44:00 <DanielK_WMDE> legoktm: global templates? lua modules?
21:44:07 <legoktm> DanielK_WMDE: phase 2!
21:44:08 <James_F> 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 <DanielK_WMDE> legoktm: :D
21:45:22 <legoktm> Er, before we start talking about global templates/modules, can we make a decision on phase 1/"First steps"?
21:45:22 <DanielK_WMDE> 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 <TimStarling> I have no objections to the first steps
21:45:41 <James_F> legoktm: Yeah, sorry.
21:45:52 <James_F> I'm in favour of Phase 1 too.
21:45:53 <legoktm> DanielK_WMDE: Yes. Which is why right now everything is just making cross-wiki API requests
21:46:38 <bd808> 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 <subbu> sorry .. i read the rfc in detail for the first time today and so i am having all these basic questions.
21:47:14 <DanielK_WMDE> legoktm: should be fine for now. not for system messages though (thinking about James_F's question)
21:47:24 <robla> 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 <DanielK_WMDE> 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:03 <DanielK_WMDE> or is it all just show?
21:48:46 * DanielK_WMDE stops asking questions and goes to check the wiki page
21:48:50 <legoktm> robla: "should legoktm begin work on implementing phase 1?" is the question I'm hoping to get answered :)
21:49:00 <bd808> yes
21:49:19 <TimStarling> regarding first step subitem "Start abstracting ForeignFileRepo remote-transcluding code into core to handle other namespaces"
21:49:24 <robla> #info question being discussed: should legoktm begin work on implementing phase 1?
21:49:28 <James_F> DanielK_WMDE: Let's not encourage new code assuming a 1:1 relationship between view and edit modes. :-)
21:50:05 <TimStarling> a subtask of that, not mentioned yet, is the fact that CSS comes with the remote description page
21:50:31 <TimStarling> abstractly, we are transcluding a bundle of content plus CSS
21:50:46 <legoktm> 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 <robla> #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 <DanielK_WMDE> legoktm: whetever content there is. wikitext for global templates. loa code for global modules
21:51:23 <DanielK_WMDE> *lua
21:51:59 <DanielK_WMDE> well, for global templates, we could also go for html based transclusion. that ties in with last week's rfc
21:52:01 <subbu> 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 <DanielK_WMDE> 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 <legoktm> 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 <subbu> DanielK_WMDE, right.
21:53:38 <subbu> i am mostly trying to wrap my head around remote-parse of transclusions ...
21:53:52 <James_F> Remote parse of local-to-remote transclusions.
21:54:06 <legoktm> 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 <TimStarling> templates obviously can be rendered remotely, that is the existing feature $wgEnableScaryTranscluding
21:55:16 <TimStarling> $wgEnableScaryTranscluding also allows local rendering with the RAW option
21:55:24 <subbu> 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 <TimStarling> 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 <subbu> right.
21:56:31 <TimStarling> but the current proposal is just to refactor the things that do exist
21:56:37 <subbu> got it. thanks.
21:57:04 <bd808> #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 <James_F> Do we have any live questions about the main question? It feels like we have agreement?
21:58:03 <TimStarling> I think we can say it is approved and move on to the "open questions" section of the wiki page
21:58:07 <DanielK_WMDE> #info TimStarling sais that $wgEnableScaryTranscluding already allows remote as well as local parsing of remote templates
21:58:15 <legoktm> https://phabricator.wikimedia.org/diffusion/EGUP/browse/master/GlobalUserPage.body.php;f1c4a384839d28f5fc622fe94e6cc079e2bde25e$67 is GUP's handling of remote modules
21:58:45 <bd808> #link https://phabricator.wikimedia.org/diffusion/EGUP/browse/master/GlobalUserPage.body.php;f1c4a384839d28f5fc622fe94e6cc079e2bde25e$67 is GUP's handling of remote modules
21:59:16 <legoktm> 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 <legoktm> 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 <legoktm> if your page is blank, or you wrap the entire thing in <noinclude> tags, then we pretend your user page doesn't exist
22:00:08 <James_F> legoktm: Except for MW: where we use '-', magically.
22:00:19 <legoktm> right
22:00:20 <TimStarling> could have a double-underscore tag instead
22:00:23 <James_F> It'd be nice to come up with a consistent system.
22:00:35 <DanielK_WMDE> TimStarling: +1
22:00:38 <James_F> __PLEASENOINHERIT__
22:00:53 * robla plans to use the #agreed command on "<TimStarling> I think we can say it is approved and move on to the "open questions" section of the wiki page"
22:01:21 <DanielK_WMDE> James_F: __OHGODPLEASENOINHERIT__
22:01:27 <legoktm> TimStarling: the double underscore would set a page prop that we could query for? I like that
22:01:35 <James_F> +1
22:01:35 <robla> #agreed <TimStarling> I think we can say it is approved and move on to the "open questions" section of the wiki page
22:01:40 <TimStarling> yes
22:03:09 <DanielK_WMDE> how would that work for non-wikitext content?
22:03:24 <legoktm> 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 <DanielK_WMDE> do we need to define a magic word syntax for other formats?
22:03:42 <James_F> Do we want to do that?
22:04:13 <legoktm> DanielK_WMDE: the implementation would define a different way to set the page property in the ParserOutput object?
22:04:22 <James_F> 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 <robla> #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 <legoktm> #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 <bd808> legoktm: quiddity
22:05:57 <bd808> grr
22:06:07 <bd808> quiddity's question is very complex
22:06:18 <DanielK_WMDE> legoktm: yea, we need to come up with a mechanism for that i guess
22:06:28 <bd808> it would be some sort of merge operation between remote and local content
22:06:56 <bd808> and subject to all the problems of keeping a local patch against a remote source
22:07:04 <TimStarling> needs a better user story or UI description I guess
22:07:46 <quiddity> 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 <James_F> My strong recommendation would be to not even try to support that use case.
22:08:30 <James_F> quiddity: "Don't".
22:09:07 <quiddity> Nod. I just wanted to ensure it is considered, as much as feasible.
22:09:08 <James_F> 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 <bd808> doing it "right" probably requires inventing a human-level AI
22:10:16 <DanielK_WMDE> 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 <DanielK_WMDE> 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 <cscott> i think quiddity's use case verges on a separate RFC for "better supporting fork/join mechanisms"
22:11:15 <quiddity> 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 <cscott> i don't think we're helped by trying to make legoktm solve all the world's problems at once
22:11:23 <James_F> cscott: Indeed. There's a use-case.
22:11:40 <bd808> cscott: agreed
22:11:41 <legoktm> DanielK_WMDE: right.
22:12:02 * quiddity nods.
22:12:06 <bd808> this is a common issue in RfC meetings I think. The "what about.." scope expansion
22:12:10 <cscott> 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 <James_F> Yup.
22:12:22 <cscott> we don't need to make them somehow be exactly the same entry in a database somewhere
22:12:40 <TimStarling> next question?
22:13:01 <bd808> Namespacing?
22:13:04 <James_F> Does legoktm need anything else? Support/ideas/help from any of us?
22:13:34 * cscott turns into a pumpkin
22:13:41 <legoktm> Those are all the questions I had for phase 1 stuff, the remaining questions are about phase 2/local parsing stuff
22:13:54 <legoktm> Yeah, namespacing. "Namespacing: should we have a "Global templates" namespace or should it be transparent like InstantCommons?"
22:13:55 <robla> #info <cscott> i think quiddity's use case verges on a separate RFC for "better supporting fork/join mechanisms"
22:14:13 <James_F> legoktm: Transparent, I think.
22:14:15 * robla probably should have used the #idea command
22:14:30 <legoktm> James_F: Not at the moment, but I will definitely ask when I need it
22:14:30 <DanielK_WMDE> legoktm: a separate namespace is basically an opt-in mechanism
22:14:31 <subbu> 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 <SMalyshev> legoktm: there probably needs to be a way to know where template comes from
22:14:43 <bd808> #info Use case of "Centralized, but locally-appendable, documentation pages" is out of scope
22:15:02 <SMalyshev> whether it is local or global
22:15:07 <James_F> 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 <SMalyshev> but that can be done with transparent too
22:15:14 <James_F> (Some == File, User, ???)
22:15:21 <legoktm> SMalyshev: why does the user need to know where the template comes from?
22:15:41 <James_F> So they can fix it, I guess?
22:15:57 <subbu> James_F, legoktm but we resolved that global templates are not the same as GUP, remote-file-repos, etc?
22:16:00 <bd808> the tabs solution would handle that right? Adding info on the imported page that points back tot he origin?
22:16:12 <TimStarling> I agree with subbu
22:16:16 <SMalyshev> legoktm: looking at GUO I see some things are still resolved in origin's context
22:16:17 <quiddity> So that they don't check locally first, but instead go directly to the actual destination.
22:17:05 <SMalyshev> legoktm: s/GUO/GUP/
22:17:18 <legoktm> SMalyshev: uh, which things?
22:17:33 <SMalyshev> legoktm: https://www.mediawiki.org/wiki/Help:Extension:GlobalUserPage#Where_content_comes_from <- these?
22:17:36 <James_F> 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 <legoktm> 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 <SMalyshev> legoktm: also, I'm not sure how permissions would work - what if you can edit local wiki but not central wiki?
22:18:33 <DanielK_WMDE> uh... btw, how do section edit links work with global templates? those are injected in a magic way on the fly...
22:19:16 <legoktm> SMalyshev: you can't edit the template then?
22:19:22 <legoktm> DanielK_WMDE: I have no idea :P
22:19:25 <bd808> 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 <James_F> Yeah.
22:19:43 <SMalyshev> 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 <legoktm> SMalyshev: wouldn't a notice that says "This template is from CentralWiki blah blah blah" like the InstantCommons/GUP notice?
22:20:24 <bd808> legoktm, TimStarling, subbu: could [[Template:Foo]] be a redirect to [[Global template:Foo]]?
22:20:33 <TimStarling> yes
22:20:41 <bd808> works for me then
22:20:43 <SMalyshev> legoktm: that's one way of knowing where the template comes from :)
22:21:27 <TimStarling> 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 <robla> #idea <bd808> legoktm, TimStarling, subbu: could [[Template:Foo]] be a redirect to [[Global template:Foo]]?
22:21:47 <subbu> what TimStarling said
22:22:10 <SMalyshev> 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 <SMalyshev> or, alternatively, we won't allow both local and global have the same name?
22:22:48 <bd808> I don't think you can delete globals from the foreign wiki
22:22:55 <legoktm> uh ^ yeah
22:22:56 <bd808> or rather should not be able to
22:23:34 <bd808> User rights on the local wiki don't extend across the foreign access api
22:23:35 <subbu> 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 <SMalyshev> 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 <SMalyshev> so I think there should be explicit mark in UI to specify it's a copy, not a real thing
22:24:10 <bd808> sure, just like instantcommons does now
22:24:32 <James_F> I think transparency is less complex.
22:24:34 <SMalyshev> (and maybe in non-UI too so that you could make proper UI in apps)
22:24:58 <DanielK_WMDE> James_F: it is. but is it less confusing? i'm undecided...
22:25:04 <bd808> attribution of the foreign source seems reasonable and necessary
22:25:22 <SMalyshev> bd808: that's what I think too
22:25:27 <DanielK_WMDE> bd808: good point: it's even required by the license.
22:25:30 <James_F> DanielK_WMDE: Less complex/confusing for users given the existing transparent things we already do, yes.
22:25:42 <James_F> DanielK_WMDE: Depends on the wiki. :-) But yes.
22:25:51 <bd808> I'm not hung up on how that attribution is surfaced in the UI
22:25:55 <SMalyshev> doesn't have to be different namespace, but I think has to be *something*
22:25:58 <subbu> 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 <bd808> "we'll figure it out"
22:26:00 <robla> 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 <subbu> so, i think explicit namespace is better.
22:26:18 <bd808> #idea attribution of the foreign source seems reasonable and necessary
22:26:45 <TimStarling> I think transparently including templates would give you an interface where there are unintended consequences of user actions
22:26:50 <bd808> #info TimStarling and subbu favor an explicate foreign template namespace
22:27:11 <subbu> typo :)
22:27:19 <TimStarling> that's why I don't think it is simpler for users
22:27:20 <bd808> heh
22:27:25 <TimStarling> it is simpler until it goes horribly wrong
22:27:42 <SMalyshev> TimStarling: exactly
22:27:44 <bd808> 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 <robla> "it is simpler until it goes horribly wrong"
22:29:18 <duploktm> sorry, my internet kind of died
22:29:25 <robla> are we going to end on my bad joke note? ;-)
22:29:37 <duploktm> :P
22:29:46 <duploktm> thanks for the discussion and input everyone
22:29:53 <robla> duploktm: I think we're just about ready to wrap things up. 30 second warning
22:30:10 <robla> 10 seconds....
22:30:24 <robla> great meeting, thanks everyone!
22:30:29 <robla> #endmeeting
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits