[WikiEN-l] We need a policy against vote-stacking
Ben McIlwain
cydeweys at gmail.com
Thu May 4 22:14:27 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jimmy Wales wrote:
> Ben McIlwain wrote:
>> Vote-stacking is wrong, it is harmful to Wikipedia, and it needs to be
>> discouraged and stopped. The simple way to do this is to block users
>> who are doing this. If it's not in the policy now, it should be.
>
> I am with you in spirit, but it seems quite difficult to define "vote
> stacking" in a way that won't be the source of endless horrible fights.
Can we at least get a policy on mass-spamming of user talk pages then?
I'm willing to put up with a mass-spammed Rfa thanks, as that isn't
trying to influence anything whatsoever, or Esperanza mailing lists or
whatever. But a single user taking it upon themselves to identify a
specific group of people and notifying them selectively about a
consensus-seeking issue currently ongoing - that is wrong.
> I have been thinking lately about some radical solution to AfD woes.
> Here are some thoughts.
>
> 1. Consensus works when there are a small number of people who have
> reputations with each other who are willing to work for compromise and
> positive progress. The importance of social capital in the process
> (earning it and spending it) can not be overemphasized.
>
> 2. As we get to be a larger community, consensus still works well on
> individual articles and areas of interest, because there are
> subcommunities in negotiation there who know each other.
>
> 3. Certain global processes, though, have turned quite bitter and sour,
> likely because it is increasingly hard to have a process of reputation
> and social capital when you have tons of people who don't know each other.
Indeed! Consensus simply fails to work on certain global processes.
Luckily we have ArbCom to deal with user conduct issues, otherwise
trying to deal with some particular users would be unworkable.
> 4. The solution to this may well be to attempt to move the "locus of
> control" for deletion decisions into subcommunities.
I like this. I was actually musing about AfdCom on #wikipedia-en-admins
two days ago. Basically it'd be a Committee of trusted people who would
decide on extremely contentious Afd situations. The way we have it
right now, with dozens of people piling on from both sides, is
untenable. The AfdCom members would be well-trusted Wikipedians who
have an excellent grasp of article inclusion policy. You could even
have an "evidence gathering" phase where experts (like the
aforementioned bridge experts) have their say. This would be much
better than the current situation which consists of a bunch of people
yelling at each other and no one in particular, trying in vain to get
their points made, when the vast majority of voters haven't really put
much thought into the issue at all.
As for the specifics of AfdCom, I think it should be small, lightweight,
and fast. ArbCom is good for what it does, but we don't need a process
that takes weeks during which a bad article could stay in limbo. My
version of AfdCom would be made of five members, any three of which can
close a matter on a given situation. The AfdCom members would be
appointed, NOT elected. I don't even want to think of how messy a
voting situation would be ... many, many votes would be based on
members' past decisions on specific subject area Afds rather than an
actual objective analysis of the merit of that person.
Most Afds would run as normal, but there would be a special application
process users could go through to bring an article to AfdCom. First,
there would have to be a non-trivial number of people on both sides, and
then AfdCom would have to decide whether to accept or reject the case,
kind of like ArbCom. This also very handily eliminates any
vote-stacking concerns. Any issue going to AfdCom is going to be
decided on by a maximum of five people, and those people are not going
to be subject to recruitment :-D
> --------
>
> I have an example, based on a nice dinner conversation I had with Sam
> Wantman. Sam knows a lot about bridges, and there is a subcommunity of
> people who know each other and work on bridge articles. Super. This is
> why our stuff on bridges is super excellent.
>
> If a bridge is listed on AfD, the result is of course likely to be a
> horrific mess. People who don't know anything about bridges are likely
> to vote based on pre-existing battles going on there between
> inclusionists and deletionists. If someone cares deeply about the
> issue, they can campaign for random other friends to come and vote. The
> admins who go through and clean it up will find it very difficult to
> figure out what to do, having little idea of the reputations of the
> various parties, and therefore have no choice to follow the disastrously
> bad rule of "one user account, one vote" ... even though this includes
> the votes of trolls, newbies, sockpuppets, meatpuppets, idiots *and*
> people who know what they are talking about and should be the ones deciding.
>
> Wouldn't it be better in this case to say, you know what, we actually
> have bridge experts, people who know about bridges, and these people
> ought to be the ones deciding, not random people on AfD.
>
> So how should this work in practice?
See above :-D
- --
Ben McIlwain ("Cyde Weys")
~ Sub veste quisque nudus est ~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
iD8DBQFEWnzDvCEYTv+mBWcRAoZkAJoC9PTBJJ+3d0bg2nnXt6xaWnkLqwCePXXf
hMThCuiAgSgLOaMLJcMfjKA=
=fGHq
-----END PGP SIGNATURE-----
More information about the WikiEN-l
mailing list