Page MenuHomePhabricator

Review and deploy GlobalUserPage extension to Wikimedia wikis
Closed, ResolvedPublic

Description

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:

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

(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.

Ok, removed a blocker: see there for comments including ops.

We still have a couple nitpicks open over the style of the footer in other bugs (with patches on their way), but no true blockers AFAICS. Ready for scheduling. MZMcBride?

I still hate the user page banner, but that's covered in T75634. I'm eager to see GlobalUserPage live on Wikimedia wikis.

@ori mentioned wanting a less specialized solution (basically proper support for shadow namespaces), but I say that perfect is the enemy of the good and we can always redo the implementation later. The underlying idea (a shared user page across Wikimedia wikis) is incredibly solid and long overdue.

@Legoktm needs to weigh in here about the status of the extension, of course, but given that the security and performance reviews are finished, I think we're pretty much good to go. I don't think we need to do any special notifications, but we should make sure this is included in Tech/News and an e-mail to wikitech-ambassadors, at least.

gerritbot added a subscriber: gerritbot.

Change 187886 had a related patch set uploaded (by Legoktm):
make-wmf-branch: Add GlobalUserPage

https://gerrit.wikimedia.org/r/187886

Patch-For-Review

Change 187888 had a related patch set uploaded (by Legoktm):
Enable GlobalUserPage on test* wikis

https://gerrit.wikimedia.org/r/187888

Patch-For-Review

Change 187886 merged by jenkins-bot:
make-wmf-branch: Add GlobalUserPage

https://gerrit.wikimedia.org/r/187886

Is there a test instance up for this anywhere? I'd like to take a look.

Is there a test instance up for this anywhere? I'd like to take a look.

Yup, at beta.wmflabs (meta/en/etc), e.g.
http://meta.wikimedia.beta.wmflabs.org/wiki/User:Quiddity
http://en.wikipedia.beta.wmflabs.org/wiki/User:Quiddity

(Note that beta.wmflabs seems to be having problems at the moment, I can't create a new account. Filing bug for that next...)

First thing of note: on the test instances it seems like updates are reflected in the inherited pages instantly, but will that be true in production? If I vandalise someone's user page, is there the possibility that that vandalism will remain globally for some time even after it's removed centrally? If yes, this may be a blocker for first release.

Second thing of note: it won't be possible to have a user page just for the central wiki any more. That's a use case we should continue to support. Could you instead do what GlobalCssJs does and designate a subpage of the user page to serve as the global user page? e.g. [[Special:MyPage/GlobalUserpage]]. This is not a blocker for first release.

Second thing of note: it won't be possible to have a user page just for the central wiki any more. That's a use case we should continue to support. Could you instead do what GlobalCssJs does and designate a subpage of the user page to serve as the global user page? e.g. [[Special:MyPage/GlobalUserpage]]. This is not a blocker for first release.

Although it's not a blocker for release, it'd be nice to get it in the first release if it's easy to do so that people don't have to move their user pages around to the new location after the fix. :-)

First thing of note: on the test instances it seems like updates are reflected in the inherited pages instantly, but will that be true in production? If I vandalise someone's user page, is there the possibility that that vandalism will remain globally for some time even after it's removed centrally? If yes, this may be a blocker for first release.

Maybe, see T76410.

Second thing of note: it won't be possible to have a user page just for the central wiki any more.

Actually it will be. See https://www.mediawiki.org/wiki/Help:Extension:GlobalUserPage#Controlling_what_content_is_displayed on how to do that.

Second thing of note: it won't be possible to have a user page just for the central wiki any more.

Actually it will be. See https://www.mediawiki.org/wiki/Help:Extension:GlobalUserPage#Controlling_what_content_is_displayed on how to do that.

Clunky... but it works.

I still think it would be better to designate a subpage instead. Then it's easier to preview your changes as you're making them, and the model for how this works is simpler because your global and wiki-specific pages are actually in different places.

First thing of note: on the test instances it seems like updates are reflected in the inherited pages instantly, but will that be true in production? If I vandalise someone's user page, is there the possibility that that vandalism will remain globally for some time even after it's removed centrally? If yes, this may be a blocker for first release.

Vandalism would be good. It'll encourage us to get caching and purging in order.

Second thing of note: it won't be possible to have a user page just for the central wiki any more. That's a use case we should continue to support. Could you instead do what GlobalCssJs does and designate a subpage of the user page to serve as the global user page? e.g. [[Special:MyPage/GlobalUserpage]]. This is not a blocker for first release.

I don't think a central wiki-specific user page matters. Is anyone asking for this and if so, why? I think re-using transclusion syntax is a perfectly valid approach here. If there are specific issues popping up, let's take a look and discuss them.

Regarding "continue to support," I'm a bit confused how we can continue to support a feature that doesn't exist yet. :-)

I don't think a central wiki-specific user page matters. Is anyone asking for this and if so, why? I think re-using transclusion syntax is a perfectly valid approach here.

Agreed. Using subpages would be a novel and disruptive approach, which would need a strong use case.

Change 187888 merged by jenkins-bot:
Enable GlobalUserPage on test* wikis

https://gerrit.wikimedia.org/r/187888

The extension is now deployed on test* wikis for testing, with the central wiki being testwiki: https://test.wikidata.org/wiki/User:Legoktm.

What's next? Meta-Wiki as central wiki and group0 as "clients"?

@Nemo_bis: The deployment calendar shows this is scheduled for deployment to all CentralAuth (non-private, non-fishbowl) wikis on 2015-02-18 (Wednesday) in the MW train window (19:00 - 21:00 UTC)

@Legoktm I am noticing that the username in my personal bar is still a red link on wikis that have a GUP, while recent changes/contribs have blue links. Is that a known issue?

@Legoktm I am noticing that the username in my personal bar is still a red link on wikis that have a GUP, while recent changes/contribs have blue links. Is that a known issue?

That's T85550.

I have a few questions…

  • As a user how do I enable/disable this feature?
  • Are talk pages mirrored, or redirected to meta?
  • How will this affect wikis I've never visited?
  • What actions cause a global profile to be created on a wiki?
  • Requesting deletion of a local profile in order to take advantage of a global profile seems like a bad experience for users esp. if this process is manual will there be any automated way to do this? - How will the flow be different for new users who have not created a profile?
  • How will new users know to go to meta to create their profile?
  • Will a Global profile make it appear that a user is active on a wiki that they are not active on, e.g. will we cause a lot of new talk page messages that users won't see?
  • How long do changes take to propigate, in a test from http://meta.wikimedia.beta.wmflabs.org/ -> http://en.wikipedia.beta.wmflabs.org/ its been over a minute and the change hasn't reflected.
  • How are we handling translation, e.g. what if a bilingual user wants to have their fr.wiki profile, be basically identical to their en.wiki profile, but in french?
  • Is there a concept of per-wiki-based content, e.g. <fr:w:include> that don't show on other wikis?
  • Is there a project page written with end users (esp. new users) as its target audience?
  • Is there a draft of the messaging to users that will go out prior to this change?
  • How do we plan on letting users know about this change?
  • Stated simply what problem is this solving?

I have a few questions…

I have many answers: https://www.mediawiki.org/wiki/Help:Extension:GlobalUserPage seems to cover all of them.

@Legoktm swung by in person and answered most all the questions I had above.

I still have three outstanding issues that I feel are still unresolved, having fully populated user pages on wikis that users don't interact with frequently could increase the likelihood of other users attempting to contact them on those wikis. We're shifting the need for users to clearly include on their talk page where you should contact them, something veteran users will likely do already but this is a very new concept to users who don't understand that they have user pages and talk pages on many projects that aren't connected.

The second issue is the need or lack their of to message to other users that global user pages are actually copies.

current message…

Screenshot_2015-02-17_16.16.41.png (90×2 px, 27 KB)

I don't know that this gives a lot of value, and also could confuse other users that they are supposed to go to that wiki in order to interact with the user, which may not be ideal or desired by the user. If this appears at the bottom of the page, it's likely to be missed on users with long user pages anyway.

Having a user go to another wiki to create a user page is a pretty confusing interaction, if a user creates their account on wikipedia, explaining to them that they going to another place "metawiki" isn't obvious, and doesn't really fit in the mental model of how users think about profiles online. Google is unifying their profiles across projects, but all edit/create links point back to that single place, you can't accidentally create a profile on gmail then need to delete it to merge it into your youtube profile later.

https://tools.wmflabs.org/erwin85/xcontribs.php?user=Jaredzimmerman+%28WMF%29 suggests that you're not familiar with the mechanics of how crosswiki communication works. That's fine: you won't need to, we're fixing it.

  1. No such risk, core warns when the talk page doesn't actually exist.
  2. The footer is very clear and it's even too visible for MediaWiki core standards.
  3. There is no such need. Creating your user page in your "home wiki" is fine and actually encouraged.

@Nemo_bis your response seems at odds with what @Legoktm said in person, that there is no real concept of home wiki in this system, and that the creation of one-off user profiles after this system is in place will cause quite a bit of headache for users having to manually request deletion of their manual user pages in order to use global profile.

I worry that you're not quite understanding my point about the notification on the profile pages that are not on metawiki, since you didn't actually address any of my concerns. But I'm glad we're in agreement that the footer is "too visible" and may not be needed at all.

Personally I think having the footer/banner is useful and necessary at least for now (similar to how we have a banner on commons files saying it's from commons). That said it may not be necessary if we have a more global profile system in the future.

I think in this case, however, we have deployed a very good, and long desired, step forward and it would be foolish to let the perfect be the enemy of the good and therefore reopening this, specific, task and un-deploying is probably unlikely. For now, however, I wonder if we should start new tasks for that to think of next steps (or config changes) rather then continuing the discussion here?

If we keep the footer, we should make at least two fixes, IMO:

  • I don't think the extension should supply its own styling. We should ensure we have a style in MW core for in-page notices like this.
  • We should not display the protocol-relative URL prefix "//".

I don't think either are deployment blockers, of course, so we can track them separately.

There are two arguments I see in favor of keeping the notice in some form:

  • It's a small hint to people performing curation tasks that this user may not be very active on the wiki in question, and may not be familiar with the specific policies and practices that apply. (A red link user page previously signaled the same thing.)
  • It's a lazy way to make the feature discoverable for others who want to turn it on.

Both of these objectives could be met in other ways -- again, we should create tasks for any obvious improvement ideas.

@Jaredzimmerman-WMF your points are all valid, but i don't they are real blockers. This feature is long requested, and we can fix the missing pieces later on.

As for your concerns themselves:

  1. Most of our users don't even know about meta. They will continue using the local user page until me make that deprecated, and all profiles truly global. This is true for newcommers too.
  2. Your concern of users getting messages from wikis they are not active on is not so concerning since people get alerts via email by default if they didn't shut it off in there preference.

@Nemo_bis your response seems at odds with what @Legoktm said in person, that there is no real concept of home wiki in this system, and that the creation of one-off user profiles after this system is in place will cause quite a bit of headache for users having to manually request deletion of their manual user pages in order to use global profile.

Sorry, I meant that the software doesn't have any concept of "home wiki". Users may have a home wiki they identify with.

If we keep the footer, we should make at least two fixes, IMO:

  • I don't think the extension should supply its own styling. We should ensure we have a style in MW core for in-page notices like this.

Could you file a bug for this please?

  • We should not display the protocol-relative URL prefix "//".

T88739: GlobalUserPage footer link should not expose readers to protocol-relative internals

Change 190691 had a related patch set uploaded (by Legoktm):
Enable GlobalUserPage extension on all public, CentralAuth wikis

https://gerrit.wikimedia.org/r/190691

Patch-For-Review

  • I don't think the extension should supply its own styling. We should ensure we have a style in MW core for in-page notices like this.

The banners's styling is being discussed at T72629: GlobalUserPage: Improve border around footer. At T72629#1044065 Krinkle suggests two possible Classes to use, but I don't know if that's the same as what you mean.

It's a small hint to people performing curation tasks that this user may not be very active on the wiki in question, and may not be familiar with the specific policies and practices that apply. (A red link user page previously signaled the same thing.)

That's a good point, in addition to the 3 previously described by Jalexander at T75634#767876 [the other task about the banner] (vis-a-vis potentially moving the banner to the top of the userpage, at least for the first few months).

Change 190691 merged by jenkins-bot:
Enable GlobalUserPage extension on all public, CentralAuth wikis

https://gerrit.wikimedia.org/r/190691

Links that should point to Meta-Wiki point to the local wiki instead, and yet are blue despite linking to non-existing local pages. WTF?!?
Better to roll back deployment and discuss first.

Links that should point to Meta-Wiki point to the local wiki instead, and yet are blue despite linking to non-existing local pages. WTF?!?
Better to roll back deployment and discuss first.

Um, what? Can you provide a link to a page with this issue?

Links that should point to Meta-Wiki point to the local wiki instead, and yet are blue despite linking to non-existing local pages. WTF?!?
Better to roll back deployment and discuss first.

Um, what? Can you provide a link to a page with this issue?

https://fr.wikinews.org/wiki/Utilisateur:Ricordisamoa
https://ca.wikibooks.org/wiki/Usuari:Ricordisamoa
https://fa.wikivoyage.org/wiki/User:Ricordisamoa

The documentation says "Wikilinks are relative, so they'll point to the local wiki." If you think that behavior isn't ideal, can you please file a separate bug?

The documentation says "Wikilinks are relative, so they'll point to the local wiki." If you think that behavior isn't ideal, can you please file a separate bug?

T89916: Wikilinks from global user pages should point to the central wiki
Anyway, if they point to local pages that neither exist locally nor are mirrored from an external site, they should be red.

Legoktm claimed this task.

Announced at https://lists.wikimedia.org/pipermail/wikitech-ambassadors/2015-February/001100.html and wikitech-l! Thanks everyone who helped get this deployed!

Anyway, if they point to local pages that neither exist locally nor are mirrored from an external site, they should be red.

created T89944.