Last modified: 2014-11-20 01:35:13 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 70576 - Review and deploy GlobalUserPage extension to Wikimedia wikis
Review and deploy GlobalUserPage extension to Wikimedia wikis
Status: NEW
Product: Wikimedia
Classification: Unclassified
Extension setup (Other open bugs)
wmf-deployment
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 70509 70584 70585
Blocks: 14759 31235 64475
  Show dependency treegraph
 
Reported: 2014-09-08 20:04 UTC by Kunal Mehta (Legoktm)
Modified: 2014-11-20 01:35 UTC (History)
13 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Kunal Mehta (Legoktm) 2014-09-08 20:04:36 UTC
The GlobalUserPage extension enables global user pages across a wiki farm. 
If a local user page does not exist, and the user has a global account attached on the local wiki and the central wiki, their user page from the central wiki will be displayed, with a notice below it indicating where it came from (similar to the File namespace).

Links:

* [[mw:Extension:GlobalUserPage]]
* [[mw:Help:Extension:GlobalUserPage]]
* [[m:Global user pages]]
Comment 1 Helder 2014-09-08 20:29:54 UTC
Can we have a helper script analogous to the one from GlobalCssJs to delete local user pages by request?
Comment 2 Kunal Mehta (Legoktm) 2014-09-08 21:35:07 UTC
(In reply to Helder from comment #1)
> Can we have a helper script analogous to the one from GlobalCssJs to delete
> local user pages by request?

I don't plan on writing one, maybe if we ask Pathoschild nicely he will? :)
Comment 3 Kunal Mehta (Legoktm) 2014-09-08 23:37:48 UTC
> 1. Create Extension: mediawiki.org page for developers and people who will
> install or configure the extension.

Done

> 2. Create Help:Extension: mediawiki.org page for the end user documentation.
> Cross-link it with the above.

Done

> 3. Request a component in Bugzilla.

Done

> 4. Get the extension code in Gerrit.

Done

> 5. Request (and respond to) a product review, if applicable

Not necessary, but people can review it if they want.

> 6. Request (and respond to) a design review, if applicable.

Only design-y thing is the footer, and Isarra took a look at that. But again, reviews welcome :)

> 7. Request (and respond to) a performance review.

Bug 70584

> 8. Request (and respond to) a security review.

Bug 70585

> 9. Show community support/desire for the extension to be deployed, if
> applicable.

See links on [[m:Global_user_pages]], there are probably plenty more discussions if someone cares.
Comment 4 Isarra 2014-09-09 06:24:02 UTC
I still don't like that border. #aaa is awfully dark when it's just white all around on both sides, especially in skins like vector with a lot of much more subtle colour transitions. The appearance in others could be subsequently HORRIBLE but that doesn't really apply to wikimedia.

Is there really no generic core class for this kind of thing where you can just apply to the new stuff like this? Be something toc, editoptions, categories, and anything else along those lines would also use, such that they all automatically match regardless of skin, or origin? Seems like that would be neater.
Comment 5 Kunal Mehta (Legoktm) 2014-09-09 21:02:38 UTC
(In reply to Isarra from comment #4)

Ok, I split that to bug 70629. I'm not sure whether it should be a blocker to this since you said it doesn't really apply to Wikimedia.
Comment 6 Isarra 2014-09-09 21:09:19 UTC
Not a blocker, just ugly. It does apply to wikimedia projects, but won't likely ever go into ARGH MY EYES territory here, at least.
Comment 7 James Forrester 2014-11-18 23:37:54 UTC
Semi-+1 from a Product perspective; I'd recommend that LCA get flagged (at the very least) first before considering it a +2.
Comment 8 MZMcBride 2014-11-18 23:47:44 UTC
(In reply to James Forrester from comment #7)
> Semi-+1 from a Product perspective; I'd recommend that LCA get flagged (at
> the very least) first before considering it a +2.

LCA presumably refers to [[wmf:LCA]]. Can you expand on why involvement from the LCA group is recommended here? Are you worried about editing disclaimer text? I'm having difficulty imagining user pages or global (wikifarm-wide) bits and pieces being a legal issue (we've had both for a very long time...), but then again, I'm not a lawyer!
Comment 9 James Forrester 2014-11-18 23:49:46 UTC
(In reply to MZMcBride from comment #8)
> (In reply to James Forrester from comment #7)
> > Semi-+1 from a Product perspective; I'd recommend that LCA get flagged (at
> > the very least) first before considering it a +2.
> 
> LCA presumably refers to [[wmf:LCA]]. Can you expand on why involvement from
> the LCA group is recommended here? Are you worried about editing disclaimer
> text? I'm having difficulty imagining user pages or global (wikifarm-wide)
> bits and pieces being a legal issue (we've had both for a very long
> time...), but then again, I'm not a lawyer!

It's the C, not the L, part of LCA that will mostly care, as it trivially impacts community audit requirements.
Comment 10 MZMcBride 2014-11-18 23:56:57 UTC
(In reply to James Forrester from comment #9)
> It's the C, not the L, part of LCA that will mostly care, as it trivially
> impacts community audit requirements.

Aha, thanks for the clarification!

I can sign off on the community part. ;-)  A big +1 from me. I'm very excited to see global user pages move forward.

In terms of communication, an item in [[m:Tech/News]] and an e-mail to wikitech-ambassadors@lists.wikimedia.org seems completely sufficient to me once a deployment date is set.

Lego: will this go to phase0 wikis first (and incrementally roll out) or are you hoping for a single-shot deployment?
Comment 11 James Forrester 2014-11-18 23:58:19 UTC
(In reply to MZMcBride from comment #10)
> (In reply to James Forrester from comment #9)
> > It's the C, not the L, part of LCA that will mostly care, as it trivially
> > impacts community audit requirements.
> 
> Aha, thanks for the clarification!
> 
> I can sign off on the community part. ;-)

I'm sorry, I missed the part where you are the responsible party for making sure community leaders like arbitration committee and their ilk are aware of changes that affect core community requirements.
Comment 12 MZMcBride 2014-11-19 00:00:59 UTC
(In reply to James Forrester from comment #11)
> I'm sorry, I missed the part where you are the responsible party for making
> sure community leaders like arbitration committee and their ilk are aware of
> changes that affect core community requirements.

No worries.
Comment 13 Krinkle 2014-11-19 00:06:17 UTC
(In reply to Kunal Mehta (Legoktm) from comment #0)
> If a local user page does not exist, and the user has a global account
> attached on the local wiki and the central wiki, their user page from the
> central wiki will be displayed, with a notice below it indicating (..)

From a user experience perspective, I think such a notice should be displayed on top. Which we do for file description pages as well (below the thumbnail, but atop the actual page contents). It should not be longer than a single line of text and not be grabbing much attention. Similar to how MediaWiki core handles foreign files (e.g. from Commons), though various Wikimedia wikis have overridden that line of text with a centred box.
Comment 14 MF-Warburg 2014-11-19 13:47:51 UTC
(In reply to James Forrester from comment #11)
> (In reply to MZMcBride from comment #10)
> > (In reply to James Forrester from comment #9)
> > > It's the C, not the L, part of LCA that will mostly care, as it trivially
> > > impacts community audit requirements.
> > 
> > Aha, thanks for the clarification!
> > 
> > I can sign off on the community part. ;-)
> 
> I'm sorry, I missed the part where you are the responsible party for making
> sure community leaders like arbitration committee and their ilk are aware of
> changes that affect core community requirements.

What are community leaders? Afaik the community has no such form of government. If you think that the only arbcom one can imagine to come to complain about a software change by virtue of being an arbcom will complain about this, why don't you simply inform it? And why don't you just add someone from the LCA department as cc?
Comment 15 MZMcBride 2014-11-19 14:21:04 UTC
(In reply to Krinkle from comment #13)
> From a user experience perspective, I think such a notice should be
> displayed on top.

Why? I think most users want to see a user page. I can't imagine many users care about where the page happens to live. I'm not convinced any header or footer is necessary at ?action=view. ?action=edit probably makes sense.
Comment 16 James Alexander 2014-11-19 23:14:22 UTC
(In reply to James Forrester from comment #9)
> (In reply to MZMcBride from comment #8)
> > (In reply to James Forrester from comment #7)
> > > Semi-+1 from a Product perspective; I'd recommend that LCA get flagged (at
> > > the very least) first before considering it a +2.
> > 
> > LCA presumably refers to [[wmf:LCA]]. Can you expand on why involvement from
> > the LCA group is recommended here? Are you worried about editing disclaimer
> > text? I'm having difficulty imagining user pages or global (wikifarm-wide)
> > bits and pieces being a legal issue (we've had both for a very long
> > time...), but then again, I'm not a lawyer!
> 
> It's the C, not the L, part of LCA that will mostly care, as it trivially
> impacts community audit requirements.

I +1 :) it's something that we've wanted for ages and the (all non blocking) concerns I brought up with lego are already mostly covered. Some people will be confused at first but the page banner (which I agree is better on top, easier to see) will help with that and something like this does not deserve a CN banner. God I wish we had the ability to do custom echo notifications easier.
Comment 17 MZMcBride 2014-11-20 01:35:13 UTC
(In reply to Krinkle from comment #13)
> From a user experience perspective, I think such a notice should be
> displayed on top.

I filed bug 73634 to track my objections to the current footer.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links