Re Todd Allen's remark about raising the threshold for article creation to auto confirmed: "Copy-pasters, spammers, and vandals will probably largely be put off by that requirement rather than bothering to fulfill it" is an interesting theory, the counter view is that vandals and other bad faith editors will do the minimum necessary to commit their damage, but a proportion of good faith editors will be lost if you make it more difficult for them.
From my experiences in Wikimedia sites and elsewhere I find the latter theory much more convincing than the former. So i judge proposals such as ACTrial on the assumption that they would be a significantly greater deterrent to good editors than to bad ones. Of course I may be wrong, as might be those who disagree with me.
This is one of those things where a controlled scientific test would be useful - another is the ongoing divide between those who think it important to template new editors and their articles as fast as possible in order that they know the flaws in their editing before they stop editing, and those like me who would like to slow down or better re channel the effort of templaters on the assumption that the faster they template the newbies the quicker the newbies will leave.
It is very difficult to achieve consensus for change where large parts of the community work on diametrically opposed assumptions. Independent neutral research might make it easier to build consensus and better decisions.
Regards
Jonathan (WereSpielChequers)
> On 26 Aug 2014, at 17:06, wikimedia-l-request(a)lists.wikimedia.org wrote:
>
> Copy-pasters, spammers, and vandals will probably largely be put off by
> that requirement rather than bothering to fulfill it
Hi all,
I note that a new Wikimedia organisation has been setup in Michigan, called
the "Wikipedia Editors Foundation Inc", as of about a week or two ago.
It seems (by the filings) to be a nice nonprofit org set up by sensible
people who care about the movement.
That said - is this a new chapter, or something similar? To whom should we
address information?
Richard Symonds
Wikimedia UK
0207 065 0992
Wikimedia UK is a Company Limited by Guarantee registered in England and
Wales, Registered No. 6741827. Registered Charity No.1144513. Registered
Office 4th Floor, Development House, 56-64 Leonard Street, London EC2A 4LT.
United Kingdom. Wikimedia UK is the UK chapter of a global Wikimedia
movement. The Wikimedia projects are run by the Wikimedia Foundation (who
operate Wikipedia, amongst other projects).
*Wikimedia UK is an independent non-profit charity with no legal control
over Wikipedia nor responsibility for its contents.*
Yes I agree that mobile is a little much. I am just proposing a simple
linked word (either author or contributors) in the by-line. It is important
to have this information in the by-line rather than to the left as this is
where people expect to find the authors / contributors.
Not attached to were it links to as long as that page contains a clear list
of the authors. Maybe we could add some of Xs tool info to a Wikipedia
based page?
--
James Heilman
MD, CCFP-EM, Wikipedian
The Wikipedia Open Textbook of Medicine
www.opentextbookofmedicine.com
Hi,
On Monday, August 25, 2014, svetlana <svetlana(a)fastmail.com.au> wrote:
>
> A first step here, I believe, is have the Teams track bugs in the open;
> from my own experience, the Flow and Multimedia folks track bugs somewhere
> else where I can't even view or comment (and even if I could, it being
> different from Bugzilla would make things harder).
All WMF Engineering teams track bugs in the open (unless they are
security/privacy related, for obvious reasons), although the use of
multiple tools doesn't help indeed. This is why we decided to move to
Phabricator.
> I'm not sure what about migration to Phabricator, but I think it's an
> operations style of thing (I'm yet to figure out how to get involved, but
> it'd make it easier for anyone to work on the new features - they are
> really documented on-wiki (thankfully they only internalise only bug
> tracking atm), although so far only in English mostly).
>
I'm not sure I understand, but in any case
https://www.mediawiki.org/wiki/Phabricator#Get_involved
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hi all.
I understand the Engineering folks used superprotect instead of /undoing/ the edit and adding 'This is a WMF action.' in edit summary. Could I please be enlightened on the reasoning behind that?
I suppose people could go and try editing other JS pages and cause havoc, but that's still possible where superprotect only affects a single page and not a namespace. Or can entire namespaces be protected and this new user right was intended to be able to prevent that easily?
Svetlana.
"Proposing a solution to the community" should not be the start of the process of involving the community.
Developers are better qualified than non-developers to say whether a prom can be solved, and how it can be solved. But the most important steps in the process include deciding what could be improved or replaced, and crucially what priority various changes could have. Developers aren't necessarily the best people to decide that, sometimes their view is an outlier. For example someone took the decision that the Article Feedback Tool was a higherh. How many developers feel bitten when they have an edit conflict?
The first stage in the dialogue should be to discuss the coding philosophy. Currently we have some coders who believe that our mission is global, and that we need to support anyone who can get onto the internet; lets call that the EBay/Amazon/Facebook strategy. Others believe that our software should be the best that it could bewe are only going
Regards
Jonathan Cardy
>
> Message: 3
> Date: Fri, 22 Aug 2014 08:48:14 +0200
> From: Dariusz Jemielniak <darekj(a)alk.edu.pl>
> To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org>
> Subject: Re: [Wikimedia-l] Next steps regarding WMF<->community
> disputes about deployments
> Message-ID:
> <CADeSpGVbVTkhP61enKhyX5c-ESNCFOFtPX8f2Yv8nqG+jD2zGw(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> one more general level solution would be having more steps: proposing a
> solution to the community (checking for support), inviting willing testers,
> after positive feedback introducing to all logged in users, and after
> positive feedback propagating on the site as a whole.
>
> Once the initial support for an idea is established, we can take for
> granted that the change should happen - but it should be up to feedback to
> see if the solution is ready, and not up to the developers' calendar (we've
> all seen what happens when the schedule is the in the case of visual editor
> premature launch).
>
> I think that WMF perhaps takes way too little use of our community as
> testers, commentators, supporters. If the community was more involved in
> development plans, it would also not be surprised by solutions which
> perhaps are important and wise in the log term, but still should not jump
> out of the box and be perceived as forced.
>
> I don't think it makes any sense to perceive WMF as just a servant. But how
> should we perceive the community? Is it a disorganized mass with no uniform
> voice, that should be shepherded into accepting solutions? Is it a valuable
> resource? Is it a full partner in planning, testing and implementing the
> solutions? I think that a lot of the latter is missing, and the fault is on
> both sides. But it is mainly up to WMF to change it, as WMF has the
> structures, staff, and resources to propose procedures there.
>
> just my two cents, anyway.
>
> dj "pundit"
>
>
> On Fri, Aug 22, 2014 at 7:54 AM, rupert THURNER <rupert.thurner(a)gmail.com>
> wrote:
>
>> Am 22.08.2014 04:18 schrieb "Erik Moeller" <erik(a)wikimedia.org>:
>>>
>>> On Wed, Aug 20, 2014 at 12:32 AM, Pine W <wiki.pine(a)gmail.com> wrote:
>>>> I am curious to hear your thoughts about the proposed Technology
>> Committee.
>>>> That idea has some community support and had been discussed at some
>> length
>>>> on the WMF Board Noticeboard.
>>>
