RFC Meeting: Shadow namespaces (2016-04-20, #wikimedia-office)
ActivePublic
Actions

Hosted by daniel on Apr 20 2016, 9:30 PM - 10:30 PM.

Description

Location: #wikimedia-office IRC channel
Meeting type: TBD
Time: 2016-04-20, Wednesday 21:30 UTC (2:30pm PDT, 23:30 CEST)
Agenda:
- T91162: RFC: Shadow namespaces

See the Architecture meetings page for more general information about this meeting (also: Phab query: list of upcoming RFC meetings, Phab query: list of all RFC meetings).

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 mentioned this in Unknown Object (Event).Apr 13 2016, 6:54 PM

• RobLa-WMF renamed this event from RFC Meeting: <topic TBD> (<see "Starts" field>, #wikimedia-office) to RFC Meeting: <topic TBD> (2016-04-20, #wikimedia-office).Apr 13 2016, 7:12 PM

• RobLa-WMF updated the event description. (Show Details)

• RobLa-WMF renamed this event from RFC Meeting: <topic TBD> (2016-04-20, #wikimedia-office) to RFC Meeting: Shadow namespaces (2016-04-20, #wikimedia-office).Apr 13 2016, 9:51 PM

• RobLa-WMF updated the event description. (Show Details)

Any chance we could start 30 minutes later? I'm going to be in class until 21:20 UTC, and then need another 5-10 minutes to find a place to sit down, etc.

I think this is reasonable as long as we can decide quickly. Any objections? (particularly TechCom members)

That'd be fine for me, as long as I don't lose network again. :)

Agh actually I'll be at the airport boarding a plane towards Germany around then. So... Depending on connectivity. :)

@Legoktm - one possibility is for us to postpone talking about T91162 for another week. Is the regular RFC meeting time always bad for you, or just next week?

Is the regular RFC meeting time always bad for you, or just next week?

It's bad for me until the end of June :(

• RobLa-WMF changed the start date for this event from Apr 20 2016, 9:00 PM to Apr 20 2016, 9:30 PM.Apr 14 2016, 4:02 AM

• RobLa-WMF changed the end date for this event from Apr 20 2016, 10:00 PM to Apr 20 2016, 10:30 PM.

It's bad for me until the end of June :(

Ok....well, how about we should for 30 minutes later than normal (barring objections in the next 24 hours). Let's make a decision on this so that we can announce the revised time in the weekly Tech News.

• RobLa-WMF updated the event description. (Show Details)Apr 14 2016, 4:11 AM

Smalyshev subscribed.Apr 20 2016, 9:16 PM

3:30 PM <wm-labs-meetbot> Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-04-20-21.31.html
3:30 PM <wm-labs-meetbot> Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-04-20-21.31.txt
3:30 PM <wm-labs-meetbot> Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-04-20-21.31.wiki
3:30 PM <wm-labs-meetbot> Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-04-20-21.31.log.html

#wikimedia-office: T91162 - Shadow namespaces

Meeting started by robla at 21:31:17 UTC. The full logs are available
at
https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-04-20-21.31.log.html
.

Meeting summary

Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ (robla, 21:31:54)
- LINK: https://phabricator.wikimedia.org/T91162 (robla, 21:33:29)
- question being discussed: should legoktm begin work on implementing phase 1? (robla, 21:49:24)
- legoktm is hoping for approval on the first steps section, and then discussion of some of the questions in open questions (robla, 21:51:12)
- some questions on how to handle CSS that comes with the remote page; GlobalUserPage has some handling for this but not perfect (bd808, 21:57:04)
- TimStarling sais that $wgEnableScaryTranscluding already allows remote as well as local parsing of remote templates (DanielK_WMDE, 21:58:07)
- LINK: https://phabricator.wikimedia.org/diffusion/EGUP/browse/master/GlobalUserPage.body.php;f1c4a384839d28f5fc622fe94e6cc079e2bde25e$67 is GUP's handling of remote modules (legoktm, 21:58:15)
- LINK: https://phabricator.wikimedia.org/diffusion/EGUP/browse/master/GlobalUserPage.body.php;f1c4a384839d28f5fc622fe94e6cc079e2bde25e$67 is GUP's handling of remote modules (bd808, 21:58:45)
- AGREED: <TimStarling> I think we can say it is approved and move on to the "open questions" section of the wiki page (robla, 22:01:35)
- 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 (robla, 22:04:22)
- Tim suggested replacing the current GUP opt-out sytem with a double underscore tag that sets a page property and can be queried for (legoktm, 22:04:52)
- <cscott> i think quiddity's use case verges on a separate RFC for "better supporting fork/join mechanisms" (robla, 22:13:55)
- Use case of "Centralized, but locally-appendable, documentation pages" is out of scope (bd808, 22:14:43)
- IDEA: <bd808> legoktm, TimStarling, subbu: could [[Template:Foo]] be a redirect to [[Global template:Foo]]? (robla, 22:21:40)
- IDEA: attribution of the foreign source seems reasonable and necessary (bd808, 22:26:18)
- TimStarling and subbu favor an explicate foreign template namespace (bd808, 22:26:50)

Meeting ended at 22:30:29 UTC.

People present (lines said)

legoktm (41)
bd808 (30)
James_F (30)
DanielK_WMDE (26)
robla (25)
subbu (20)
SMalyshev (20)
TimStarling (19)
cscott (6)
quiddity (5)
wm-labs-meetbot (3)
duploktm (3)
stashbot (2)
Scott__WUaS (1)
mobrovac (1)

Full transcript:

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

1	21:31:17 <robla> #startmeeting T91162 - Shadow namespaces
2	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.
3	21:31:17 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
4	21:31:17 <wm-labs-meetbot> The meeting name has been set to 't91162___shadow_namespaces'
5	21:31:17 <stashbot> T91162: RFC: Shadow namespaces - https://phabricator.wikimedia.org/T91162
6	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/
7	21:32:15 <robla> hi folks!
8	21:32:38 <legoktm> hello
9	21:32:54 <legoktm> I think everyone here is familiar with the shadow namespaces concept, right?
10	21:33:05 <robla> task: T91162
11	21:33:05 <stashbot> T91162: RFC: Shadow namespaces - https://phabricator.wikimedia.org/T91162
12	21:33:29 <robla> #link https://phabricator.wikimedia.org/T91162
13	21:33:57 <legoktm> I wrote up a "first steps" section at https://www.mediawiki.org/wiki/Requests_for_comment/Shadow_namespaces#First_steps
14	21:35:09 <legoktm> And wanted to make sure that sounded reasonable
15	21:35:36 <legoktm> I'm going to start implementing all of that...now basically.
16	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?
17	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?
18	21:36:32 <subbu> i meant: links to resources besides the remote resource being accessed
19	21:37:04 <DanielK_WMDE> yea, good point. where to links point to?
20	21:37:04 * robla regrets not filling in the "meeting type" field in https://phabricator.wikimedia.org/E162
21	21:37:17 <legoktm> robla: approval for the first steps section, and then discussion of some of the questions in open questions
22	21:38:11 <SMalyshev> so I understand this would be including rendered HTML from other wikis? what are the security implications?
23	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
24	21:38:26 <Scott__WUaS> Hi
25	21:39:02 <subbu> how does this work for templates? ex: {{remote-tpl\|link=[[my_local_article]]}}?
26	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).
27	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
28	21:40:11 <legoktm> subbu: everything would be parsed in the context of the remote wiki, and links would point to the remote wiki
29	21:40:32 <subbu> hmm ... need to ponder that.
30	21:40:59 <SMalyshev> legoktm: so templates are resolved with respect to remote wiki?
31	21:41:01 <legoktm> James_F: you mean something like https://www.mediawiki.org/wiki/Extension:MessageCommons ?
32	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?
33	21:41:32 <James_F> legoktm: Yeah, ish.
34	21:41:39 <SMalyshev> that may limit template usage that use context (stupid example: Welcome to {{this page}}, {{user}})
35	21:41:40 <legoktm> bd808: GlobalUserPage and ForeignFileRepo*, but yes
36	21:41:54 <James_F> legoktm: Plus also all the complications about edit vs. create vs. "over-ride".
37	21:42:00 <DanielK_WMDE> subbu: it would be extremely hard to make it work correctly otherwise, i think.
38	21:42:53 <cscott> James_F, legoktm: [Low priority] I'm curious about using this approach for the Module namespace.
39	21:42:54 <subbu> wouldn't action=expandtemplates done remotely handle {{remote-tpl\|link=[[my_local_article]]}} and such?
40	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)
41	21:43:34 <legoktm> subbu: kind of, but what if the template does a {{#ifexist:}} on "my_local_article"?
42	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?
43	21:43:54 <subbu> right ...
44	21:44:00 <legoktm> cscott: modules and templates need local parsing, which would be phase 2
45	21:44:00 <DanielK_WMDE> legoktm: global templates? lua modules?
46	21:44:07 <legoktm> DanielK_WMDE: phase 2!
47	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.).
48	21:44:13 <DanielK_WMDE> legoktm: :D
49	21:45:22 <legoktm> Er, before we start talking about global templates/modules, can we make a decision on phase 1/"First steps"?
50	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
51	21:45:37 <TimStarling> I have no objections to the first steps
52	21:45:41 <James_F> legoktm: Yeah, sorry.
53	21:45:52 <James_F> I'm in favour of Phase 1 too.
54	21:45:53 <legoktm> DanielK_WMDE: Yes. Which is why right now everything is just making cross-wiki API requests
55	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.
56	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.
57	21:47:14 <DanielK_WMDE> legoktm: should be fine for now. not for system messages though (thinking about James_F's question)
58	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
59	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?
60	21:48:03 <DanielK_WMDE> or is it all just show?
61	21:48:46 * DanielK_WMDE stops asking questions and goes to check the wiki page
62	21:48:50 <legoktm> robla: "should legoktm begin work on implementing phase 1?" is the question I'm hoping to get answered :)
63	21:49:00 <bd808> yes
64	21:49:19 <TimStarling> regarding first step subitem "Start abstracting ForeignFileRepo remote-transcluding code into core to handle other namespaces"
65	21:49:24 <robla> #info question being discussed: should legoktm begin work on implementing phase 1?
66	21:49:28 <James_F> DanielK_WMDE: Let's not encourage new code assuming a 1:1 relationship between view and edit modes. :-)
67	21:50:05 <TimStarling> a subtask of that, not mentioned yet, is the fact that CSS comes with the remote description page
68	21:50:31 <TimStarling> abstractly, we are transcluding a bundle of content plus CSS
69	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
70	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
71	21:51:19 <DanielK_WMDE> legoktm: whetever content there is. wikitext for global templates. loa code for global modules
72	21:51:23 <DanielK_WMDE> *lua
73	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
74	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.
75	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
76	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.
77	21:52:56 <subbu> DanielK_WMDE, right.
78	21:53:38 <subbu> i am mostly trying to wrap my head around remote-parse of transclusions ...
79	21:53:52 <James_F> Remote parse of local-to-remote transclusions.
80	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
81	21:54:08 <TimStarling> templates obviously can be rendered remotely, that is the existing feature $wgEnableScaryTranscluding
82	21:55:16 <TimStarling> $wgEnableScaryTranscluding also allows local rendering with the RAW option
83	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. :)
84	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
85	21:56:22 <subbu> right.
86	21:56:31 <TimStarling> but the current proposal is just to refactor the things that do exist
87	21:56:37 <subbu> got it. thanks.
88	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
89	21:57:14 <James_F> Do we have any live questions about the main question? It feels like we have agreement?
90	21:58:03 <TimStarling> I think we can say it is approved and move on to the "open questions" section of the wiki page
91	21:58:07 <DanielK_WMDE> #info TimStarling sais that $wgEnableScaryTranscluding already allows remote as well as local parsing of remote templates
92	21:58:15 <legoktm> https://phabricator.wikimedia.org/diffusion/EGUP/browse/master/GlobalUserPage.body.php;f1c4a384839d28f5fc622fe94e6cc079e2bde25e$67 is GUP's handling of remote modules
93	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
94	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
95	21:59:26 <legoktm> specifically regarding the opt-out feature GlobalUserPage currently has
96	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
97	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
98	22:00:08 <James_F> legoktm: Except for MW: where we use '-', magically.
99	22:00:19 <legoktm> right
100	22:00:20 <TimStarling> could have a double-underscore tag instead
101	22:00:23 <James_F> It'd be nice to come up with a consistent system.
102	22:00:35 <DanielK_WMDE> TimStarling: +1
103	22:00:38 <James_F> __PLEASENOINHERIT__
104	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"
105	22:01:21 <DanielK_WMDE> James_F: __OHGODPLEASENOINHERIT__
106	22:01:27 <legoktm> TimStarling: the double underscore would set a page prop that we could query for? I like that
107	22:01:35 <James_F> +1
108	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
109	22:01:40 <TimStarling> yes
110	22:03:09 <DanielK_WMDE> how would that work for non-wikitext content?
111	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
112	22:03:40 <DanielK_WMDE> do we need to define a magic word syntax for other formats?
113	22:03:42 <James_F> Do we want to do that?
114	22:04:13 <legoktm> DanielK_WMDE: the implementation would define a different way to set the page property in the ParserOutput object?
115	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?
116	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
117	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
118	22:05:53 <bd808> legoktm: quiddity
119	22:05:57 <bd808> grr
120	22:06:07 <bd808> quiddity's question is very complex
121	22:06:18 <DanielK_WMDE> legoktm: yea, we need to come up with a mechanism for that i guess
122	22:06:28 <bd808> it would be some sort of merge operation between remote and local content
123	22:06:56 <bd808> and subject to all the problems of keeping a local patch against a remote source
124	22:07:04 <TimStarling> needs a better user story or UI description I guess
125	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.
126	22:07:47 <James_F> My strong recommendation would be to not even try to support that use case.
127	22:08:30 <James_F> quiddity: "Don't".
128	22:09:07 <quiddity> Nod. I just wanted to ensure it is considered, as much as feasible.
129	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
130	22:10:03 <bd808> doing it "right" probably requires inventing a human-level AI
131	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.
132	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.
133	22:11:06 <cscott> i think quiddity's use case verges on a separate RFC for "better supporting fork/join mechanisms"
134	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.
135	22:11:20 <cscott> i don't think we're helped by trying to make legoktm solve all the world's problems at once
136	22:11:23 <James_F> cscott: Indeed. There's a use-case.
137	22:11:40 <bd808> cscott: agreed
138	22:11:41 <legoktm> DanielK_WMDE: right.
139	22:12:02 * quiddity nods.
140	22:12:06 <bd808> this is a common issue in RfC meetings I think. The "what about.." scope expansion
141	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.
142	22:12:18 <James_F> Yup.
143	22:12:22 <cscott> we don't need to make them somehow be exactly the same entry in a database somewhere
144	22:12:40 <TimStarling> next question?
145	22:13:01 <bd808> Namespacing?
146	22:13:04 <James_F> Does legoktm need anything else? Support/ideas/help from any of us?
147	22:13:34 * cscott turns into a pumpkin
148	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
149	22:13:54 <legoktm> Yeah, namespacing. "Namespacing: should we have a "Global templates" namespace or should it be transparent like InstantCommons?"
150	22:13:55 <robla> #info <cscott> i think quiddity's use case verges on a separate RFC for "better supporting fork/join mechanisms"
151	22:14:13 <James_F> legoktm: Transparent, I think.
152	22:14:15 * robla probably should have used the #idea command
153	22:14:30 <legoktm> James_F: Not at the moment, but I will definitely ask when I need it
154	22:14:30 <DanielK_WMDE> legoktm: a separate namespace is basically an opt-in mechanism
155	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.
156	22:14:35 <SMalyshev> legoktm: there probably needs to be a way to know where template comes from
157	22:14:43 <bd808> #info Use case of "Centralized, but locally-appendable, documentation pages" is out of scope
158	22:15:02 <SMalyshev> whether it is local or global
159	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.
160	22:15:10 <SMalyshev> but that can be done with transparent too
161	22:15:14 <James_F> (Some == File, User, ???)
162	22:15:21 <legoktm> SMalyshev: why does the user need to know where the template comes from?
163	22:15:41 <James_F> So they can fix it, I guess?
164	22:15:57 <subbu> James_F, legoktm but we resolved that global templates are not the same as GUP, remote-file-repos, etc?
165	22:16:00 <bd808> the tabs solution would handle that right? Adding info on the imported page that points back tot he origin?
166	22:16:12 <TimStarling> I agree with subbu
167	22:16:16 <SMalyshev> legoktm: looking at GUO I see some things are still resolved in origin's context
168	22:16:17 <quiddity> So that they don't check locally first, but instead go directly to the actual destination.
169	22:17:05 <SMalyshev> legoktm: s/GUO/GUP/
170	22:17:18 <legoktm> SMalyshev: uh, which things?
171	22:17:33 <SMalyshev> legoktm: https://www.mediawiki.org/wiki/Help:Extension:GlobalUserPage#Where_content_comes_from <- these?
172	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".
173	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
174	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?
175	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...
176	22:19:16 <legoktm> SMalyshev: you can't edit the template then?
177	22:19:22 <legoktm> DanielK_WMDE: I have no idea :P
178	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]] ?
179	22:19:38 * robla plans to use #endmeeting very close to 22:30 UTC
180	22:19:42 <James_F> Yeah.
181	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"
182	22:20:23 <legoktm> SMalyshev: wouldn't a notice that says "This template is from CentralWiki blah blah blah" like the InstantCommons/GUP notice?
183	22:20:24 <bd808> legoktm, TimStarling, subbu: could [[Template:Foo]] be a redirect to [[Global template:Foo]]?
184	22:20:33 <TimStarling> yes
185	22:20:41 <bd808> works for me then
186	22:20:43 <SMalyshev> legoktm: that's one way of knowing where the template comes from :)
187	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
188	22:21:40 <robla> #idea <bd808> legoktm, TimStarling, subbu: could [[Template:Foo]] be a redirect to [[Global template:Foo]]?
189	22:21:47 <subbu> what TimStarling said
190	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?
191	22:22:35 <SMalyshev> or, alternatively, we won't allow both local and global have the same name?
192	22:22:48 <bd808> I don't think you can delete globals from the foreign wiki
193	22:22:55 <legoktm> uh ^ yeah
194	22:22:56 <bd808> or rather should not be able to
195	22:23:34 <bd808> User rights on the local wiki don't extend across the foreign access api
196	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.
197	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
198	22:24:08 <SMalyshev> so I think there should be explicit mark in UI to specify it's a copy, not a real thing
199	22:24:10 <bd808> sure, just like instantcommons does now
200	22:24:32 <James_F> I think transparency is less complex.
201	22:24:34 <SMalyshev> (and maybe in non-UI too so that you could make proper UI in apps)
202	22:24:58 <DanielK_WMDE> James_F: it is. but is it less confusing? i'm undecided...
203	22:25:04 <bd808> attribution of the foreign source seems reasonable and necessary
204	22:25:22 <SMalyshev> bd808: that's what I think too
205	22:25:27 <DanielK_WMDE> bd808: good point: it's even required by the license.
206	22:25:30 <James_F> DanielK_WMDE: Less complex/confusing for users given the existing transparent things we already do, yes.
207	22:25:42 <James_F> DanielK_WMDE: Depends on the wiki. :-) But yes.
208	22:25:51 <bd808> I'm not hung up on how that attribution is surfaced in the UI
209	22:25:55 <SMalyshev> doesn't have to be different namespace, but I think has to be something
210	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.
211	22:25:59 <bd808> "we'll figure it out"
212	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
213	22:26:05 <subbu> so, i think explicit namespace is better.
214	22:26:18 <bd808> #idea attribution of the foreign source seems reasonable and necessary
215	22:26:45 <TimStarling> I think transparently including templates would give you an interface where there are unintended consequences of user actions
216	22:26:50 <bd808> #info TimStarling and subbu favor an explicate foreign template namespace
217	22:27:11 <subbu> typo :)
218	22:27:19 <TimStarling> that's why I don't think it is simpler for users
219	22:27:20 <bd808> heh
220	22:27:25 <TimStarling> it is simpler until it goes horribly wrong
221	22:27:42 <SMalyshev> TimStarling: exactly
222	22:27:44 <bd808> the namespace manes sense as long as redirects can "hide" it from most users
223	22:28:05 * robla thinks several programming languages should have that slogan ;-)
224	22:28:18 <robla> "it is simpler until it goes horribly wrong"
225	22:29:18 <duploktm> sorry, my internet kind of died
226	22:29:25 <robla> are we going to end on my bad joke note? ;-)
227	22:29:37 <duploktm> :P
228	22:29:46 <duploktm> thanks for the discussion and input everyone
229	22:29:53 <robla> duploktm: I think we're just about ready to wrap things up. 30 second warning
230	22:30:10 <robla> 10 seconds....
231	22:30:24 <robla> great meeting, thanks everyone!
232	22:30:29 <robla> #endmeeting

Links for the next 4 meetings:

2016-04-27: https://phabricator.wikimedia.org/E66/32
- Tentative agenda: T122942: RFC: Support language variants in the REST API
2016-05-04: https://phabricator.wikimedia.org/E66/33
- Tentative agenda: T130528: RFC: PSR-6 Cache interface in Mediawiki core
2016-05-11: https://phabricator.wikimedia.org/E66/34
2016-05-18: https://phabricator.wikimedia.org/E66/35

• 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 RFC Meeting: Shadow namespaces (2016-04-20, #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 invited: ; uninvited: .

daniel updated the event description. (Show Details)

daniel updated the event description. (Show Details)Dec 9 2016, 7:44 AM

daniel renamed this event from ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office) to RFC Meeting: Shadow namespaces (2016-04-20, #wikimedia-office).

RFC Meeting: Shadow namespaces (2016-04-20, #wikimedia-office)ActivePublicActions