Talk:GlobalProfile/design/LQT Archive 1

Red linked userpages or redlinked talkpages?
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:
 * 1) whitelisted editors
 * 2) editors with bluelinked talkpages and no recent warnings
 * 3) editors with redlinked talkpages
 * 4) editors with recent warnings.

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 http://en.wikipedia.org/wiki/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. WereSpielChequers 14:50, 22 June 2011 (UTC)
 * 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.
 * I am currently of the mind that providing default User and User_talk pages for new users is a good idea, if only so that we can show them that these things exist at all. The sooner new users understand that discussion pages exist is better, in my opinion.
 * As far as templates are concerned, I am very leery of them. We have some research that tells us that "manually saying mean things" to new users is far, far preferable to "dropping a template on their talk page".  Templates are rather forbidding, generally, and overall poorly designed.  Most are blocks of text which instantly cause users to drop into "scan" mode.
 * It might be better to connect this with WikiLove to help show appreciation.--Jorm (WMF) 19:05, 22 June 2011 (UTC)
 * 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). WereSpielChequers 14:27, 23 June 2011 (UTC)

SUL
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. WereSpielChequers 15:06, 22 June 2011 (UTC)
 * 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.--Jorm (WMF) 18:57, 22 June 2011 (UTC)

Private Sandboxes
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. WereSpielChequers 15:06, 22 June 2011 (UTC)

Retooling
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.--Jorm (WMF) 23:16, 23 June 2011 (UTC)
 * 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. WereSpielChequers 18:12, 24 June 2011 (UTC)
 * 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.--Jorm (WMF) 18:49, 24 June 2011 (UTC)
 * 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. --Yair rand 01:11, 30 June 2011 (UTC)
 * (Also pointing out that StructuredProfile would probably need some changes to work on certain projects. On Wiktionary, for example, "Interests" and "Languages" overlap enormously.) --Yair rand 01:13, 30 June 2011 (UTC)
 * 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. --Purodha Blissenbach 23:27, 3 July 2011 (UTC)
 * Note that Extension:Draft and Extension:SocialProfile and Extension:ConfirmAccount respectively already do much to some of the suggested tasks. --Purodha Blissenbach 23:27, 3 July 2011 (UTC)

Public Versus Private Data
If we want to learn from other social networks, we may want to add a feature of degrees of semi-privateness, which allows to share personal data with some peer-group, or all logged-in users, but not the general public.

For instance, I know several users of one or another regular local editors meetup who share considerably more personal info with each other in real life than they would be willing to publish on their user pages.

In a non-WMF context, I have been in contact with project contributors who could not make their contributions to the project in ways that their employers would recognize, though their employers interests were not touched. While the project communication was otherwise through public mailing lists, these specific persons had to use non public channels when their expertise, skills, and knowledge could be identifying them. --Purodha Blissenbach 23:26, 29 June 2011 (UTC)