Last modified: 2014-11-20 01:35:13 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]]
Can we have a helper script analogous to the one from GlobalCssJs to delete local user pages by request?
(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? :)
> 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.
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.
(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.
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.
Semi-+1 from a Product perspective; I'd recommend that LCA get flagged (at the very least) first before considering it a +2.
(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!
(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.
(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?
(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.
(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.
(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.
(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?
(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.
(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.
(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.
