On Thu, Dec 23, 2010 at 2:44 AM, Carcharoth <carcharothwp(a)googlemail.com>wrote;wrote:
On Thu, Dec 23, 2010 at 3:18 AM, Stephanie Daugherty
<sdaugherty(a)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(a)lists.wikimedia.org
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l
--
Faith is about what you really truly believe in, not about what you are
taught to believe.