In the following months we are going to experiment a bit with OpenBadges, in the context of the Facebook Open Academy program and under the coordination of Parent5446. Those badges are related to MediaWiki users, therefore they have some relation with this GlobalProfile feature.
Adding a note here just in case.
Cool!
Do they plan to build actual integration in terms of Open Badges in the user interface? Or just do the plumbing for a badge backpack etc. in MediaWiki?
Re: GlobalProfile/design#Collected Data and the "future elements" list. This is a thread to gather other suggestions.
As a user, I'd like quick-links to the foreign/sister projects that I'm active on. Even just a basic link to m:Special:CentralAuth/Quiddity (and a better default sort-order there) would be helpful.
Currently, I make a manual list at w:User:Quiddity#Other project watchlists, which works, but is imperfect.
As a power-user, I'd like to more easily discover interesting gadgets and scripts, to increase my efficiency and happiness as an editor. I'd like to see which of the Special:Preferences#mw-prefsection-gadgets someone else has enabled (if they select a checkbox to make that info public), and also to get quick links to a user's vector/common/global .css and .js files. - (Every few months, I discover a new script or gadget, that I wish I'd known about long before. Other editors who do the same tasks I do, probably have good tips and tricks, but it's hard to find out.)
You may want to take a look at b:pt:User:Helder.wiki/Tools/UserPages.js (specifically "getUserTools" and "processUserTools"). 
(and maybe Gadgets 3.0 too)
Very interesting question, Quiddity! Why are you asking? Can we expect a reactivation in this area? Just in case it's useful, last Spring I tried to work on something similar to Global Profile, but for the MediaWiki / Wikimedia tech community. The initiative was stopped, after reaching to the conclusion that the best was to be patient and wait for Global Profile etc. See Project:New_contributors/Roadmap#People.
Suggestions:
There's no re-activation afaik, I was just looking at the page again, and having ideas, and noting them down in case they were useful later on.
The whole concept has pleasant echoes of iGoogle, which I miss. Useful user-selectable modules.
I really like some of the elements in the old mockups, and I think it would be good to
Relatedly, Enwiki has the ~7 year old w:WP:User page design center which contains some good ideas, and some ghastly aesthetic-mixing, and an overwhelming proliferation of options. I'm horrified that anyone might send a newcomer there, but it's the best breakdown of 'available modules' that I know of.
(Thanks for the link to Project:New contributors, I've watchlisted those pages, and will absorb on a later day.)
Good points! Good to finally have languages as structured data. Few confirmations and suggestions:
I wrote a rather flowery compliment about GlobalProfile that just got deleted, why I'm uncertain. I just hope everyone realizes it was a sincere compliment, however unorthodox. My apologies if it should not have been place here. --HectorMoffet (talk) 07:16, 10 March 2012 (UTC)
This initiative seems predicated on the idea that other editors are targeting editors with redlinked userpages as probably editing in badfaith. An alternative theory is that the truly sure mark of a newbie is a redlinked talkpage, so the best way to protect goodfaith new editors is to welcome them once you've checked their first edit and found it to be in goodfaith. In my understanding Huggle etc divides users into four broad groups:
Editors with bluelinked userpages and redlinked talkpages are currently an anomalous subset of group 3 that includes spammers and myspacers.
Efficiently moving users more quickly from group 3 to group 2 and group 2 to group 1 would reduce the load for Hugglers and other patrollers, thus making recent changes more efficient, less stressed and hopefully less likely to miscategorise a goodfaith newbie as a vandal.
Possible ways to do this include:
A user preference for those who have hotcat installed to "welcome unwelcomed new editors with a personalised welcome based on the category I've just added to their new article". This would require a bit of code using the wikiproject or more likely category to tailor the welcome to include a Wikiproject or Wikiprojects that they might find interesting - we already have w:en:User:DASHBot/Wikiprojects/Templates the table for this, we just need the code. Newpage patrol would I believe be transformed if there was an option to auto welcome newbies whose articles you had patrolled. This could just be done by creating an extra button for patrollers where the article is by a Newbie - so [Mark this page as patrolled and welcome author] would appear as well as [Mark this page as patrolled]. T
Linking Huggle and the other vandalism reversion tools and manual vandalfighters so that white lists can be generated more efficiently would speed up the transition from the second group to the first. I revert vandalism manually and welcome good faith users using Twinkle, but I'm pretty sure that when I check an edit and do nothing that does not currently contribute to getting that editor whitelisted.
I believe that there are currently a couple other experiments being run by the Account Creation Project team that involve automatically creating User and User_talk pages - specifically with the goal of avoiding the "redlink" problem described above. In some ways, the impetus for this project is driven from that - if we remove the redlink notifications, then page patroller difficulty increases radically so we need to look into ways to avoid that.
That's really interesting re dropping a template on the talkpage. The only research I've seen so far shows that welcomed users are more likely to stay, despite a high proportion of welcomed users getting a "welcome I've tagged your article for deletion" welcome, and as we know those users rarely stay, so the logical assumption is that welcoming really works. If there has been other research on this I'd love to see it (I know there been some focus group sort of stuff as to what people say they like, and templated welcomes do badly there. But if the actuality contradicts the focus group I'd be inclined to go with what works in practice even if it shouldn't work in theory).
Many of our goodfaith editors are actually visitors from other wikis, some of our badfaith editors are also. If we are coding something like this it would be cool to have an option that automatically replicated your userpage or at least a link to it when you first edited on a project.
I think my ideal implementation for this would be to have all the data stored centrally on a cross-wiki server (data.mediawiki.org, maybe) so that your profile will be accessible on every wiki that you have unified. This will help alleviate the problem you're describing.
That risks increasing the amount of foreign language userpages on wikis. Better I would suggest to have a userpage per language - this would be more easily be done if Wikinews, wikiquote wiktionary etc etc were all views of one wiki and we moved towards one wiki per language.
Multilingual Wikimedians tend to have their different userpages in the appropriate languages, and they are most likely to be active cross wiki
If the user has a central user page, he can use
{{#switch:{{CONTENTLANGUAGE}}
|fr = User page in French
|pt = User page in Portuguese
|en|#default = User page in English
}}
to get it displayed differently depending on the wiki's language code.
There was an interesting article recently about how some sites handle the problem of forgotten / wrongly remembered user names by showing personal data on the login form. GlobalProfile seems to be ideally suited for such a function.
Heh! I read the exact same article the other day and started cogitating on it.
That article discusses login screen usability but it does not discuss log in security. I'm uncertain how many of the suggestions there we would want to implement. Nominally, all of the user names on a wiki are available, so there's no real harm in exposing that, however.
This will require thinking.
I think I'm going to retool this after watching several user tests that show me that the concepts we were thinking to do regarding profile pages were not radical enough.
There is definitely potential for a major change to the way we handle userpages, and user information. Two of the ideas you might want to consider are keeping private drafts and sandboxes that only the editor can see. If the system autosaved drafts privately in userspace the way that gmail does then editors with flakey PCs or who edit from multiple locations would have a much better editing experience. I've lost several updates due to PC crashes and I can't be alone in this. Equally if people could choose to designate a sandbox in their userspace as private and only viewable by them then we wouldn't need to wonder what was in it. There are also two high priority things that members of the community have long been begging for - cross wiki watchlists and cross wiki userpages. Either of those would be a major upgrade for those wikimedians who operate across multiple projects.
I'm thinking much more along the lines of cross-wiki user pages right now, which would require technology that would enable cross-wiki watchlists in the future. More information coming soon.
Cross-wiki userpages sounds like it would be largely unhelpful across sister projects (information relevant to one project is not that likely to be relevant to another), and pretty much impossible across languages (how would translation be done?), imo.
(Also pointing out that StructuredProfile would probably need some changes to work on certain projects. On Wiktionary, for example, "Interests" and "Languages" overlap enormously.)
Leaving the question of relevance of certain data for varying project wikis aside - having structured data makes translation a manageable task. Volunteers at translatewiki.net will be translating all prompts and all selecteable answers. Rendering software will be using these translations as appropriate. That's all.
Rehman suggested on bug 4547 (Support crosswiki template inclusion (transclusion => interwiki templates, etc.)):
(...)maybe (upon enabling cross-wiki transclusion from Commons), we could also create an option in Special:Preferences where checking it would transclude the Commons userpage to all other wikis.
For example, checking it would simply replace the userpage with a function like {{User:Rehman}} (or {{Commons:User:Rehman}}) on all other userpages...
My understanding of the reasons why we are concerned as to the contents of users sandboxes and other userpages is that they are published on the Internet and available for all to see. If we created an option for editors to have a private page that only they could see then presumably we wouldn't need to police it, and that could be used by editors as a sandbox, or for any other lawful purpose. We'd presumably want to limit the space of that to avoid misuse, but I think it would be a logical extension of the userpage work.