Defining quality

The only exception I have to your post, Woodwalker, is that I believe that the quality framework should (yes normative) be consistent across the various communities. I think if we create a framework that communities pick and choose from that the end result will be sorely lacking. In this quest for a broad reaching yet specific framework, we really need to take into account the needs of all communities. This way, the guidelines we craft will speak to all of the communities and get their buy-in.

@Bhneihouse: actually, I'm not against Wikimedia forcing projects to do this or that, if it increases quality. I just think Wikimedia's abilities are very limited. Some time ago now, Wikimedia pushed for a strict guideline about biographies for living people on all projects. I guess it hasn't been put into place yet in most projects. This illustrates how little real power Wikimedia seems to have.

What I meant was to tell projects: 'Look, if you want to increase your project completeness (one of the 17 quality factors I found), do this. If you rather want to increase your verifiability, you should instead do that.As is obvious from this example, larger projects have the luxury to go for depth, whereas small projects will probably like to focus on quantity. Size is just one reason why projects may have different priorities. Cultural, personal and other differences also play a role.

Some implementations may help increase a certain factor, yet be destructive for another factor. If, for example, the amount of non-encyclopaedic content is a priority, a project could be advised to use flagged revisions. This reduces the amount of IP-users.^* Less IP-users means less non-encyclopaedic content is added^* and the hardcore group of editors will have more time to focus on removing non-encyclopaedic content. On the other hand, another project may find that their priority is to raise their project balance, because they have little coverage of certain fields. They want to encourage more new users and can be advised not to use flagged revisions because it decreases the influx of newbies.^*

I agree that all projects should in the end have the same quality goals, but they may be in different project phases and therefore need different approaches.

^* I'm not sure this is true, it's just an example.

I do agree on Wikimedia (WMF)'s power to obtain change. What it can do is change the river-bed, so the water will "most likely" move in a "somewhat predictably" different manner ( :) ) I also agree on how projects differ, etc.

Where I don't think it works is that you're perhaps assuming decision making finesse beyond most project's capabilities in your main example, I fear. (I'm trying to imagine an enwiki debate where user consensus was sought on which position the project was in and which guidance (or any) to follow. "Herding cats" doesn't come into it!) Nice in theory, but sadly, dead in the water in any practical sense. Might work for a few projects, at most?

I do take the idea it's an example. But I think we can shape and effectively alter certain things only.

True, I know I'm philosophizing for a perfect world. However, the imperfectness of decision-making isn't really our problem, is it? We can give advice, what projects do with it (or rather: what they are practically able to do with it) isn't up to us.

Off-topic: the fact that large communities tend to be slow in decision-making surprises me. From a logical POV, only so many things can be said in a certain discussion. After that, there's either consensus or not. If there's no consensus a poll is held, if that's indecisive, a vote is held. In larger projects, there are more users able to accommodate/coordinate a poll or vote when the discussion gets to the point where people are repeating themselves, so decision-making should be easier, but it doesn't seem to work that way.

It's not our problem, but that's the same as the law of gravity not being our problem when designing a plane.

We're making recommendations; the recommendations are to maximize specific desirable effects; we need to make the recommendations based on a best analysis and understanding of the way reality will work on any given suggestion. Some will work better than a "perfect world" case, some worse. We're not designing for a perfect world, we're designing for the communities, human nature, encyclopedic issues, and public, that we're used to.

The criteria isn't "what might work best if the world wasn't like this", it's "what's most likely to deliver given these things". In that sense anticipating what can cause an idea to crash and burn, and what's workable or likely to be productive, is precisely what we should be considering.

good points, but I really do think that a consistent framework would serve Wikipedia's goals. That would take the guesswork out of "what stage" a project is in, how much content is up, etc. I do not agree with going for filling in the spaces and letting quality lag in the process. I believe that a standard should be consistent at all times. Otherwise, if we start a new language Wiki for example, for the Abkajeckfa language, there might be a lot of new pages with very little consistency and quality that do not mirror the overall brand of Wikipedia. People reading the pages may not understand that low quality is NOT Wikipedia. In truth, whenever Wikipedia allows that which is not consistent with its brand to exist as Wikipedia, it dilutes the brand. Kind of like IBM and laptops. There is a reason Lenovo is now not IBM. IBM truly isn't about laptops any more than Dell is really about consumer products. Wikipedia is about accurate knowledge. Standards in keeping with Wikipedia's core ideals and values keep Wikipedia being Wikipedia, no matter how it expands.

They're consistent. A standard framework can exist, that allows for human nature and cultural or wiki-community variations.

But so long as a wiki (eg Abkajeckfa) is poor quality, then for people who read that and inconveniently don't read enwiki or de/frwiki, that is Wikipedia, and we are poor quality. That said, inevitably the wider world will judge us by our bigger wikis alone.

this is the thing with brand, as you guys will see when someone posts my graphic (LOL) or not see, or as you may already know from your own experiences with various brands -- ONE customer experience can and will define the entire brand for any given customer/user. ONE bad wiki -- one incomplete, poorly written, unvetted wiki -- can and will define the Wikipedia brand for millions of users. As any brand specialist will tell you -- it is common knowledge that getting a customer back is SO MUCH HARDER that just keeping him or her in the first place.

that said, consistency is key. users need to know at all times what state a wiki is in, and they need to understand what the ultimate goal is. With the current structure for wikis, that is just not possible. Currently, wikis are sometimes really bad or incomplete or... yet they still carry the Wikipedia brand.

Originally, creating Wikipedia out of nothing took a lot of daring just to make it exist. But the same conditions of introducing a brand no longer exist. Now Wikipedia is an established brand and users see it as a valid information source. Going to the next level may mean changing the way the infrastructure works in order to stay TRUE to the Wikipedia brand. That may mean that inaccurate or misleading information may never be tolerated as a "public" or "finished" wiki. That may mean that we have to create an interim wiki for discussion and work (FT2's idea off list that we are still hashing out a bit in small group -- email me if you want to be included in the email) that eventually gets posted with a "done" (or close to done) status... there are many possibilities, but in the end, the brand that users experience as Wikipedia matters.

@FT2 (10:37, 27 November 2009): seems true, but that could bring us to an advice of the following sort:

'Well, actually we know how you can increase quality standards dramatically, but because of the way you're cooperating right now we assume you're not able to, so instead we'll tell you something that has little effect but certainly works'.

I think we're allowed to think big (I mean also: larger time-scale) and assume some problems in decision-making can be overcome in the future. Additionally, not all communities have become paralysed to the same degree as the en-wp community.

Because of the paralysis in decission-making, progress can only be made by creating new constructive ways (like our wizards), not by removing or changing old ways. This cannot continue eternally, people can only work with a limited quantity of 'red tape'. That's why I'm still optimistic that something will be done to make decission-making more effective in the future.

It's not just the amount and complexity of 'red tape', it is also the fact that 'red tape' is a tool which can be bent to purpose by all and sundry. In fact, a creative editor can make the red tape mean exactly what he or she wants it to mean. Red tape is in this respect more of a liability than an asset, where edit wars can be won by the editor most adept at bending the laws of reality to their own intent than others. I already have a fairly radical proposal up to the effect that we move away from what we now seem to have somehow ended up with, policy driven content, and back to what we once had and which made Wikipedia such an amenable and fascinating environment in which to work, one of content drive content. The paper which underpins the thinking for this is to be found here: Task force/Enhance community health and culture task force/Making Wikipedia a Happier Community. Policy appears to be a fundamental enemy of content and quality of content. Good faith, well researched edits by editors who care about their subjects results in ineffably better articles than anything cobbled together from a bunch of dubious web pages annotated with copious citations until your eyes blee with an overarching eye to policy compliance.

I like this part of the observation: that it's easier to suggest a new place to go or a new tool, than to suggest a change to existing wiki-cultural aproaches.

But I think the communities are looking for significant changes or findings here, so we're free to say "if you aren't working this way, try it, that's our conclusion" and provided it's viable they might.

However (and I think this is your point)... the more you tell people "kill that old approach and do this" instead of the softer and easier "start moving this direction", the more you risk an outright rejection by significant numbers.

In other words, it has to be a path that's got a good chance of people following it, otherwise it's pointless. So our optimum result might be categorized somewhat openly as the best path that has a good chance of enough people following it to make the necessary difference.

Human nature, variety of views, and inertia, will ultimately limit what we can achieve in any given "bite" at the quality cherry. Best to respect there are limits on the achievable (although not giving in lightly), and see what's the most we can progress quality for this time.