I fully agree with Risker. I feel this discussion is only (mainly)
looking at enwp. Harassment probably exist on all versions but the
seriously of the issue look very differently.
Being the most active user and sysop on a smaller version (svwp) I do
not recognize the issues being discussed. On our version we do not need
any arbcom, we are getting very good to resolve all issues without, on a
page where all are welcome to participate (and block of more then a day
is not allowed of an productive contributor by just one admin, it must
have been discussed first and reached consensus first) . And
haressements are not more frequent than that is is possible to handle
them individually (which we do and have a low tolerance level)
And besides from us being few that makes this issue easier to tackle, my
opinion is that the key for us is the yearly confirmation of admin
rights. It is interesting to follow these over the years. First the
reasons for non-support was if clear misuse, after a few years
aggressive discussion style, but now it is being about the need to
friendly and cooperative (but all OK to be tough on trolls, bad
behaviour unserious editing)
perhaps instead of building up new rules etc, it could be worthwhile to
study good working versions instead and learn from them?
Anders
Den 2016-06-07 kl. 21:18, skrev Risker:
Hmmm. I find this recommendation concerning. There *might* be some
validity on large projects with hundreds of administrators, but there are a
lot of projects with only a few admins, and they were "selected" because
they were willing to do the grunt work of deletions, protections, and
blocks. Nobody was selecting them to handle large-scale harassment.
Indeed, I cannot think of a single administrator even on a large project
who was selected because of their ability or their interest in handling
harassment incidents. There's pretty good evidence that it is not only not
a criterion seriously considered by communities, but that absent the
interest or willingness to carry out other tasks or demonstration of
aptitude for other areas of administrator work, an admin candidate would
not be selected by most communities, even large ones where harassment is a
much more visible concern.
There is also no basis for putting forward that mandatory training for any
administrator function would be useful on a global scale. How does one set
up a mandatory training program for carrying out page protection, given
that every large project has a different policy? What happens if an
administrator doesn't "pass" a mandatory program? Are they desysopped, over
the objections of their community?
I'll point out in passing that there is not even consideration of a formal
global checkuser training program - again, the local policies vary widely,
and the types of issues addressed by checkusers on different projects is
very different.
Risker/Anne
On 7 June 2016 at 15:01, Sydney Poore <sydney.po...@gmail.com> wrote:
My suggestion is to come up with a general type training that can work for
all administrators and functionaries since all have the freedom and
permission to do all types of work on WMF projects. And that training
should be mandatory.
Then people who are focusing on a particular type of administrative or
functionaries work can take more advanced courses that could be mandatory
for doing some types of work.
Sydney
Sydney Poore
User:FloNight
Wiki Project Med Foundation
WikiWomen's User Group
Facebook https://www.facebook.com/sydney.e.poore
On Tue, Jun 7, 2016 at 2:10 PM, Pine W <wiki.p...@gmail.com> wrote:
Hi Sydney,
Thanks for that link. I think that for now I would suggest avoiding
making
the training mandatory because we won't know how successful it is until
after we've used it for awhile. After the training has been tested and
refined based on feedback, and if the consensus is that the training is
helpful, then at that point we could consider making this a required
annual
training.
I could foresee is that, on wikis that have arbitration committees or
other systematic ways of dealing with administrators who mess up, the
ArbComs and/or the community could say that those administrators who have
demonstrated weakness in areas that are addressed by the training will be
required to take or re-take the training as a condition of keeping their
admin permissions.
My hope is that the training will be of such good quality, and so
interesting and useful to administrators, that many administrators will
*want* to take the training or at least be curious enough to try it. Big
carrot, small stick. We can escalate from there if the training develops
a
track record of success.
I would think of success as being measured in two ways: administrators'
feedback about the training shows a consensus that they found it helpful,
and communities report higher levels of satisfaction with their
administrators as shown in the difference between surveys that are done
before on multiple wikis (1) before the training starts and (2) after 6
or
12 months of the training being rolled out.
Comments welcome, including suggestions about how to measure the success
of the training.
Pine
On Mon, Jun 6, 2016 at 7:58 PM, Sydney Poore <sydney.po...@gmail.com>
wrote:
Rosie Stephenson-Goodknight suggested Annual Training during the
Harassment Consultation, 2015.
https://meta.wikimedia.org/wiki/Harassment_consultation_2015/Ideas/Annual_training
If you've not seen it, it is worth your time to read the talk page
discussion.
Sydney
Sydney Poore
User:FloNight
Wiki Project Med Foundation
WikiWomen's User Group
Facebook https://www.facebook.com/sydney.e.poore
On Mon, Jun 6, 2016 at 9:17 PM, Pine W <wiki.p...@gmail.com> wrote:
I have created
https://meta.wikimedia.org/wiki/Grants:IdeaLab/Training_for_administrators
and would welcome feedback there.
On the subject of block evasion, I have some ideas but would defer to
our
experienced CheckUsers.
Pine
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
