On Thu, Dec 23, 2010 at 2:44 AM, Carcharoth carcharothwp@googlemail.comwrote:
On Thu, Dec 23, 2010 at 3:18 AM, Stephanie Daugherty sdaugherty@gmail.com wrote:
Of further concern to me is that we have far exceeded the limits of a wiki as an effective collaboration platform. Collaboration at small scale remains possible but talk pages dont scale well at all to tens of thousands of users.
Most articles don't have tens of thousands of users. Most only have tens to fifties. Only the very largest discussions need to involve all active users, and even there the numbers taking part are not in the tens of thousands.
I agree with you there. However, at any given time, that's a good
guestimate of how many editors we have that can reasonably be considered "active". The typical numbers are probably in the neighborhood of 25-500 depending on the issue, and those discussions fall apart even at that scale. Current "archiving" and "hatboxes" can be extremely disruptive to discussions at project-level, but they are absolutely necessary under the current system in order to keep the page readable. Project-scale discussions are important because they do affect "everybody", in that every participant in the project is a stakeholder, and they are vitally important in guiding our future, yet, in most cases, they break down long before anything resembling consensus can be reached. The combination of talk page structure and a vigorous discussion can make it very easy to keep growing a conversation without ever making progress towards consensus, and with only a little persistance required to take part, we have our own form of fillibuster that allows only a very small handful of editors to preserve the status quo on almost any issue by keeping the discussion moving away from consensus. The process of large discussions is so painful and stressful that it's been a major factor in retirements and wikisuicides - editors that are passionate enough about the project to participate in these sort of discussions tend to be scarred pretty badly by the experience.
Further the software was never designed to be used in the way we use it to implement process on wiki. Complex template based processes and conversations based around heavy template usage are unnatural, inefiicent, error prone, and have too steep a learning curve for newcomers.
I agree templates can be confusing, but they provide great flexibility. If you are going to move to a different system, it has to be one that editors can make changes to and not rely on developers to make requested changes.
For it to be an improvement over the current system, I think it needs to be
an in-between. There needs to be enough "cost" to implementing and changing a template that it's not a trivial thing to do, otherwise we'll see "template creep" continue to be a problem. Templates simply shouldn't work in a lot of the ways they are now used. Our AFD process is an example of "template creep" going too far. It's a heavily template driven process, that's confusing and unwieldy enough that the "regulars" tend to use javascript tools just to navigate through it. Templates weren't built to do things that complicated, and using them in a way like that is prone both to breakage, and to scaring users off.
As a radical solution, define templates at the page level. One article, one template. Give us a form-based interface to move through a template-based article. Make heavy use of advanced formatting within the templates themselves if you must, but advanced formatting should be completely absent from articles themselves - in other words, templates should have access to more markup than articles, and articles should lose the ability to use the more complex markup features.
This sort of approach has a few advantages to us. The biggest is that it allows us to impose a consistent style on articles. which would give us a more professional feel, and would allow us to make changes across the project in a consistent manner. The second advantage, is that it gives editors a framework, to know what kind of information we want to see within an article. Templates become a sort of standard outline for an article as opposed to the sort of templates we are used to.
Aside from that, move the articles towards semantic markup, and define styles for that markup across the project. A new "what you see is what you mean" editor for that markup would completely remove any need for formatting considerations from the average editor, make it easy to produce content for that markup, and would enable software tools to be used more effectively (and in many cases, more safely) for the advanced users. It may even make it possible to validate content to some degree for accuracy as well as spelling, grammar, and style.
These issues are critical to fix if we are to scale but there is so much inertia that i fear it would only be possible if changes were forced. There are a lot of well established editors that actually benefit from the status quo - the complexity and confusion inherent to policy process and discussion tend to create a sort of inner circle of editors that can effectively leverage the situation to their advantage through the combination of knowledge and persistance.
Most policy discussion and process doesn't affect articles, surprisingly enough. Not directly, anyway. To be able to edit articles well, all you really need is a general sense of how things work (using examples from other articles that are clearly good examples), a willingness to learn and discuss with others, some good sources to work with, a basic ability to write and organise your thoughts, being able to balance what different sources are saying, and some common sense.
Everything else is instruction creep, but often useful instruction creep as long as you don't pay too much attention to it. Pay attention to it when you need to, but at other times just use common sense and ask yourself if what you are doing will improve, or lead to an improvement in, an article or set of articles.
Good point. IAR is something a lot of us need to be reminded of. I think a
lot of the problems that happen are where someone tries to move from working at an article or topic area into policy areas. This happens for various reasons. Sometimes an editor gets drawn into the issue when they get "bitten" by another editor applying that policy too forcefully. Sometimes they see something done a certian way and ask "why can't we do it this way, it would be better". Sometimes they have an interest in the janitorial aspect, or they may just truly take interest in policy. Swimming in a river of piranhas would be more pleasant than many of the first experiences people have with project-wide collaboration, and if they care enough to stay in that river, they keep getting bitten for their efforts. That's the sort of thing I'm most concerned about - editors that have a genuine interest in making the project better often end up pushed to retirement or wikisuicide. The "Beware of the tigers" essay is a good read here, but the problem is that, where policy is concerned, it's often a jungle full of them.
Consensus decisionmaking is an important part of our heritage and our future as Wikipedia, but at this stage, and at this scale, we need to look hard at how we implement it as a process, particularly at how we resolve the stalemates, deadlocks, and fillibusters. We are often paralyzed where it comes to the sort of technical and policy reforms that we need to preserve and improve effectiveness, editorial integrity, and fair process, and that has lead to a Wikipedia that can't sustain the sort of growth we've experienced without a high rate of attrition. The people we lose from this are too often our best editors - highly skilled article writers, wikignomes, tool authors, and janitors, and that hurts us badly - even if the project will go on without them, we lose tremendous opertunities to be better every time we chase off someone dedicated.
It would be worth reconsidering some sort of community leadership position going forward. In the early days, that was Jimbo's role, but as the project matured, that was diminished, and we developed into a huge community without much in the way of a clear vision or direction. I don't think we need to create another "GodKing" type position, but we do need someone in a position to guide us gently in the right direction when high-level conflicts would otherwise stall us. I'd say the role needs to have some functions for conflict resolution and moderation, as well as for determining consensus. This would keep ArbCom from having to become involved in many high-level disputes. It doesn't necessarily have to come with any special software permissions, and doesn't even require that someone be an administrator, but it does need to come with enough authority to break up conflicts and deadlocks relatively early, and could take the shape of an elected committee structured similarly to ArbCom. For a start, the job would primarily be that to mediate. Where mediation fails, the authority would need to exist to interpret whether or not consensus exists, and to determine or implement processes for moving a deadlocked discussion towards consensus - imposing structured discussions at first, and if there's agreement for that sort of thing, administering advisory and official polls when there's no other way to reach a decision. The ability to impose an interim solution to an editing conflict would be nice, but I'm wary of that as I'm sure others will be, so I think we'd need to see how it went first. The idea is that community leaders would deal with conflict, while arbitrators would continue to deal with misconduct.
Anyway, I'm already bordering on TL:DR material here, but I think there's plenty of food for thought here :)
Carcharoth
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l