A lot of questions. The first question is related to the first key question for the quality task force. In short: we have the 5 pillars (at least most projects do). Somewhere between these pillars (following links to individual guidelines) five core requirements for content can be found: it should be verifiable, neutral, balanced, findable and encyclopaedic (at least for the -pedia projects, other projects have similar requirements). These words have been used for several different purposes. What I mean is:
- Verifiable means content is based on sources that can be trusted. Sources should preferably (1) be primary, (2) be as recent as possible, in that order. The order is to reduce the anecdotal way of referencing that is a plague in Wikipedia.
- Neutral means the content reflects the broad consensus among experts/specialists in literature.
- Balanced means sections of the content are proportional to the importance given to it by those experts.
- Findable means the reader can find the content easily. This is where the wiki structure plays its unique role (categories, links, navigation templates, etc).
- Encyclopaedic means it is not written in a format different from what is expected in an encyclopaedia. Other projects (wiktionary, wikiquote, wikibooks, etc) have instead of this a similar requirement of format.
These five core requirements can imho still be worked out in more detail and should really be better advertised and implemented. This has to be done if we want to attract users that add quality and readers that search for quality. One of the most demotivating factors for quality users is when they experience ongoing obstruction from users that don't understand these requirements. Woudloper 20:37, 17 November 2009 (UTC)
A related question I've asked is whether it's appropriate and fair – to them and the project – to dump users unfamiliar with encyclopedia writing into the project, without some clear-cut "newcomers' guide".
- (I started writing a newcomer's manual to try and help on this).
There was a time that anyone who wasn't a vandal and clicked "edit here" was fine, because it wasn't that big and standards weren't that demanding, but now we're a lot more demanding in 2 ways: we demand they pick up with a fast learning curve, and we set higher and more detailed standards.
We still want users to just click and edit. Can we reconcile these wishes?
Re: whether it's appropriate and fair – to them and the project – to dump users unfamiliar with encyclopedia writing into the project, without some clear-cut "newcomers' guide".
It depends on what you want from your new editors and why you want to let everybody have the freedom to edit right away. As the English wikipedia has already taken shape and refined many times over, newcomers may
- keep the information updated
- fix errors
- write new articles.
Basically the 5 pillars are just common sense. (You don't say things loudly unless you have a reference.) So why not? the wikipedia community is still evolving, and rightly so. Hillgentleman 21:50, 17 November 2009 (UTC)
The 5 pillars are just a start. They seem common sense, I agree. Unfortunately, for a lot of users they are not. In some cases because they are newcomers, in some because they don't understand, in some because they don't want to understand. Most of these users need to be contacted personally to be told about things like the 5 pillars, even if such guidelines are linked in welcome messages. The need to be constantly helping and educating others about the basics takes valuable time from experienced users. This problem is present both at the larger and smaller projects, though the amount of patience with and the ways of contacting newcomers differ enormously. Tackling it can be done in two conventional ways:
- Make guidelines, 'newcomers manuals', etc more visible. They should be easy to find. A link should be present when a new or unregistered user edits a project, preferably close to the 'save' button.
- If this is done, it can be assumed new users should know the guidelines when editing. They can therefore be treated with less patience, which saves time for experienced users.
Apart from this, new ways of editing have been introduced at several larger projects. An example are flagged revisions, a system which filters contributions of experienced users from those of the inexperienced. In its most strict sense flagged revisions can even be used to make contributions of inexperienced users temporary invisible (except for themselves). As of yet, the influence of such systems on quality is not yet clear to me. I think their exact influence on projects where they were introduced should still be examined into more detail.
Apart from this another open door: the sharing of all information and initiatives among projects could be better. If a manual is written at a certain project, other projects should be made aware of its existence. Someone, perhaps the foundation, has to play a more active role in this, perhaps by posting an 'up for translation' message at local message boards or village pumps. Of course not in an authoritarian way. The choice is made by local communities, but they should be made aware of the choices of others.
Someone on enwiki has written a "new article wizard" (and updated v2.0). If people are educated as they go (in sensible size doses) then it could pay off in quality terms. If we want quality articles, and we want mass editorship, then one starting point is that most editors won't be used to this kind of writing or the standards, policies and arcana that have evolved. Bringing them sufficiently up to speed - ensuring whatever they do is guided - is a common way to resolve that, in the "real world". If you look at companies that want wide usage of complex programs for example (Microsoft's a good example), it's worth noting the effort they put into interfaces, wizards, help systems, and "newcomer guidance". There's usually an "advanced" setting for users who don't need/want that.
Wizzards are indeed a very useful and potentially time-saving tool. Your example is for adding good content. However, wizzards can also be used for instructing how to remove bad content. Above I tried to define content quality by five requirements (it's just a try). What could help is making such wizzards for all of these requirements, then translate them for all projects. For example 'how to deal with POV/unencyclopaedic/biased/etc content'.
A "Report a problem with this page/article" link or icon on every page, that leads to a pop-up wizard for advising how to handle problems? I'd say "yes" to that. It's something we could do with the present-day setup.
One of the wikis (polish, maybe?) has something like this. Might be worth checking into.
The new article wizard is certainly a step in the right direction, as far as tapping the pools of less tech-savvy editors go. Such initiatives should be prioritized, and the Wizard should be included in the more friendly (usability wise) Beta being developed. --Piotrus 19:57, 25 November 2009 (UTC)
I'd like to see the same principles elsewhere, with generic "wizard hooks" in the code, and a "Wizard:" namespace so users can actually code up the wizard contents for these hooks on-wiki:
- New account wizard, asks users "These are the issues with name choice, please choose a name"... asks "have you already got an account or used one in the past" and notifies them the basics of sock policy"...
- Edit war wizard, detects 3+ reverts (not quite 3RR) and advises users "I see you've reverted this page a few times recently, are you sure?" -> Yes / Help me! / Cancel my edit
- Citation wizard, "I see you've added a chunk of text (or new article) but there aren't any citations in it. Would you like help in adding citations so other users can check your edits are verifiable?"
- Controversial topic wizard, advises users "You're editing a controversial topic. Would you like some hints and tips first?"
- Deletion wizard: [if we gave users a "delete" button even if not admins] -> "You've clicked "delete", but you aren't an administrator. Wikipedia has a number of deletion tools and processes. Would you like guidance on the appropriate one to use, and on making your request?"
- ... etc ...
In other words, don't demand users read most policies, or hit them with a stick for not doing so. Instead, guide them when they have actual need for the information.
So the links for a deletion wizard might be buttons for "Help me!" and "Cancel request", and also a link for "View policy summary" which opens a short popup that includes a link to "View full policy". The popup doesn't need to say everything covered in the policy, just what's relevant to the action they're doing.
- (I also wouldn't make this "ad hoc". I'd design a proper "Mediawiki Wizards" extension, so that all that would be needed in future is a bugzilla request: "Please add a wizard hook for X, that provides parameters P, Q, R". The conditions it fires (parameter based) and the actual wizard pages, are then configurable on-wiki, either via a "Wizard:" namespace, or stand-alone like AbuseFilter.)