|Thread title||Replies||Last modified|
|Refresh for this data?||0||00:57, 20 March 2012|
|Reverts||4||23:13, 28 January 2012|
|Hostility chasing away participants||0||00:24, 2 January 2012|
|Red link: Post to social media feeds||0||11:58, 20 October 2011|
|New Userpages for Existing Editors||3||19:39, 13 March 2011|
|Feedback on Multimedia section||0||01:24, 2 March 2011|
|This is a draft of the Product Whitepaper||3||21:24, 30 November 2010|
You could ask editors why are you reverting edits. What reasons are there? Maybe there are some rules or reasons that could be deleted?
Part of the problem is you don't even need a reason to revert. No one likes their work lost, but there are good reasons for most things in Wikipedia that people can learn and adapt to. I know I did. The problem is if there's no reason or an arbitrary reason, it's confusing and very frustrating. You read what you gather from the rules, try your best, and still it comes down to a couple editors who just don't like what you're doing.
Exactly. They couch their argument in wikipedia-specific lingo. Another particularly insidious manuever is to suggest that you are violating policies for which you may be blocked.
Wikipedia blocks are quite reasonably specific and time-delimited, nevertheless they have a chilling and inhibitory effect, no one wants them,and if one has never gone through a block or an Arb, it can be very put offish.
I would describe it as "hostile". The revert method is the path of least resistance, and it is the most likely to be perceived like it's a bully stomping on your sand castle.
Agreed. No one likes seeing their work reverted.
But it's also one of the central features of the Wiki system. So we're not going to get rid of reverts.
The next best thing would be to help new users understand why things are reverted. (One idea: for new users, have the revert edit summary CC'd to their user talk page.) Another helpful strategy would be to steer new users away from high-conflict pages that are more likely to be reverted, and push them towards improving articles where novices are likely to be most helpful.
I have come and gone a few times over the last decade. Every time I have left it was because of vague hostility, or some sort of territoriality. I'm doing bug hunting lately, and the same problems are making it much less fun than it normally is. Again, I wonder if the stress is unhealthy and I should quit for a while.
During the usability initiative tests, we found that user accounts would get repeatedly reverted for the edits these new users would make. We also found that they hardly noticed when they got messages informing them of these reversions. While this wasn't the aspect of wikipedia editing we were testing at the time, we all felt kind of bad that some of these users who made their first edits would go home later that day and find their edits were reverted, so I wrote a quick note on the test user's user pages explaining who they were and the nature of the account. The results were incredible; pretty much none of the edits were reverted afterwards, and, in fact, some editors took the initiative to take the intent of the edit and work it in to the page to meet policies. How useful would that be for all people? So, my proposal is the following changes:
- Creating a default userpage for a user after they've made 10 or so edits (assuming they don't have a userpage yet) explaining that they are new, they've been a wikipedian since (whenever), made (n) edits, clearly have an intent on being a wikipedian but might need someone to show them the ropes.
- Notifying users via email when they get new messages, something that they can turn off, but have this on for new accounts by default so they know that they have a message in the system.
- Some version of the "don't bite the newbies" template that lets people know the user they're about to message has only made a low number of edits, they're new, and to be helpful if they can be. Also work in conjunction with developers of tools like Twinkle so that users have to take extra measures to revert a "first edit" or "first 5" edit.
I think we can test the top and bottom ideas independently.
I concur with all of this and would add that for more experienced users who edit on controversial topics, admins often apply contentious nitpicks and the prospect of going to ArbComm is very intimidating. There are definite topical areas where this problem crops up,and not only the user-firendliness but also the prestige and perception of reliability of Wikipedia is endangered if its articles lose NPOV. Certainly, there are strata of societies and specific nations and even languages which enjoy greater computer access and computer literacy. Wikimedia are in danger of being perceived as organs of biased coverage if there are not studies which can produce mechanisms to assure NPOV through easily accessible grievance resolution for less experience persons who are more interested in their areas of expertise than in learning the art of wikilawyering.
Proposal: that a sysem be considered wherein less experienced persons who feel that they are subject to ham handed admin reverts can enlist representation. Of course, they can now, but most experienced editors are loathe to take up a case, and probably restrict their assistance to a tip here and there.
Thank you for thoughtful consideration of these comments.
Nobody really wants to bite the newbies (or would openly admit to doing it on purpose). Anything we could do to prevent this accident would help. If we assume good faith, then most people would stop biting newbies if they knew they were newbies. And if editors are truly acting in bad faith and trying to scare the newbies off, then labeling the newbies will make it more obvious when someone is just being a dick.
I like this idea.
I like this idea. As an administrator and Wikipedian for the past five years, I have experienced the levels of friendliness going down on the English Wikipedia year by year. Creating new articles and editing existing ones is not only a difficult prospect for new users (who understandably have a lower threshold for tolerance) but also for experienced users using sockpuppets to test the system. However, recent changes patrollers are visibly more careful with non-redlinked users. (edit: at the same time we must actively advocate anonymity on our projects)
I think the priorities for Multimedia are right on - better uploading, easier reviewing. A couple of specific suggestions...
- Better uploading - I'm still amazed that we have no good solution for uploading from Flickr. Yes, this is a very specific use-case, but it's a huge one. We have some buggy toolserver scripts, but this ability should have been built into Commons years ago.
- Easier reviewing - Before we do anything else on this issue, we should review the tools that currently exist (there are a lot) and see: what people are already doing, how they're doing it, and evaluate if any of the existing tools could be adopted or rewritten by the WMF as a more integral part of Commons.
The goal of this document is to provide the fact base and analysis to support the prioritization of WMF development efforts. It was initially called the Product Roadmap doc, but started to feel more like a whitepaper than a roadmap doc. We can change the name to whatever people reflects the content and purpose of the document.
I'll be adding content to this doc over the next several days. In the meantime, please feel free to add/edit/comment. Looking forward to everyone's feedback.
- First drop a line in the Village pump or that one page is going to be overlooked.
- Second drop a line in talk page of users who still hang around here like Randomran.
Comment: I will help but frankly it's difficult to have faith in a Foundation that handled our volunteer support like a sort of expendable commodity.
Last edit: 18:26, 30 November 2010
Thanks for suggestions. I'll post this in Village Pump once there is more of the draft up for people to review. Ditto on talk page of users who have been involved in the Strategy project.
Curious about your comment re: volunteer support. I'd be happy to discuss this further. Please leave a message on my talk page if you'd like to discuss.
22.214.171.124 18:27, 30 November 2010 (UTC)