I responded to the security/monitoring question at phabricator. With some tweaks, it's
probably a reasonable way to start. Again, though, even though I think that your biggest
concern (perhaps rightly so) is the creation of brand new wikis, there seem to be a whole
lot of good reasons to test this whole idea first. And the well-established,
near-enough-to-approval tests, are the best ones to test on.
Sent from Outlook<http://aka.ms/weboutlook>
From: Langcom <langcom-bounces(a)lists.wikimedia.org> on behalf of
Sent: Sunday, July 29, 2018 4:39 AM
Subject: Langcom Digest, Vol 58, Issue 16
Send Langcom mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Langcom digest..."
1. Re: Please read: Fixing Incubator (Amir E. Aharoni)
Date: Sun, 29 Jul 2018 11:39:25 +0300
From: "Amir E. Aharoni" <amir.aharoni(a)mail.huji.ac.il>
To: Wikimedia Foundation Language Committee
Subject: Re: [Langcom] Please read: Fixing Incubator
Content-Type: text/plain; charset="utf-8"
As promised, a more detailed reply. (Sorry it took me a bit—my laptop was
Arjan's main question was about monitoring vandalism across multiple
incubator wikis, which are suggested in the proposal. And my answer is
no—at the moment I don't have more details about it.
Obviously, this cannot be done without a clear and agreed solution to this
problem, or at least an agreement to make a temporary conditional
experiment. That's why I wrote in the Phabricator task: "Patroling all such
domains for vandalism must be at least as easy as it is for Incubator". I
don't have a complete solution to this, but it's clear that it's a
sine-qua-non condition for moving forward.
My plan was to bring this up at Incubator's own community discussion pages.
The closest thing that I have currently to a written proposal to monitor
wikis is the one by Martin Urbanec at his comment on Phabricator:
Does this sound like a beginning of something sensible and feasible? Or is
it too technical and complex and inappropriate?
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
“We're living in pieces,
I want to live in peace.” – T. Moore
2018-07-26 11:32 GMT+03:00 Arjan Verheijden <arjanverheijden(a)hotmail.com>om>:
I have to tell that I am not very happy about this being discussed without
consulting the admins of the Incubator. There has been no announcement
about this discussion, nor even a simple message on admin's talk pages
about this. If I weren't subscribed to the LangCom mailing list, I wouldn't
even have known this discussion was taking place.
As a lot is pretty technical, I can only comment on what I think this
proposal is about.
I agree that there are some major issues on the Incubator concerning edit
comfort (prefixes, standard templates/modules, wikidata, etc.). If I
understand correctly, the idea is to split off the most active tests into
own semi-subdomains. A big problem that will have to be addressed with this
is that separate domains require way more monitoring. Now, with all tests
in one wiki, it is easy for the Incubator team to remove spam, vandalism,
errors in pages, etc, and easy to run bots for broken redirects etc. With
separate domains, that will become an impossible task, unless somekind of
admin interface is created in which all tests can be monitored from one
I saw in the Phabricator task: "Patroling all such domains for vandalism
must be at least as easy as it is for Incubator." Is anything known about
the status of this? Has a solution already been found?
*Från:* Langcom <langcom-bounces(a)lists.wikimedia.org> för Amir E. Aharoni
*Skickat:* den 26 juli 2018 07:42
*Till:* Wikimedia Foundation Language Committee
*Ämne:* Re: [Langcom] Please read: Fixing Incubator
2018-07-25 20:04 GMT+03:00 Steven White <Koala19890(a)hotmail.com>om>:
... I really don't want this
discussion to go in the direction of arguing about historical languages
Me, either. But for the moment Incubator needs to continue to serve those
... I even welcome you to create semi-artificial
criteria that would put the number of the first test wikis at around 50 :)
I can manage that.
I guess that I'd do one of the following:
1. Define what does "a while" mean. For example, we can decide, somewhat
arbitrarily, that a project under incubator.wikimedia.org
in which there
were no edits for over a year, will be considered
"dormant" and that a
wiki won't be created for it until somebody
2. Just use case by case intuition.
Right now I am using a blend of the above. I tend to use page creations,
not edits, because from time to time you get random edits from people who
sweep through and update the name of the current prime minister in the
infobox, without really doing anything else, and I'm not sure those really
They don't. It should all be done in Wikidata, for a lot of reasons, and
this is one of those reasons.
That said, I also ignore page additions by certain people I know are doing
maintenance (me, Liuxinyu970226, others). I also ignore cases where the
only page addition comes from the automatic creation of a redirect after a
page move. Finally, for this purpose, we ignore single page creations from
> - Conversely, many tests open with a
flurry of activity (over 1
2 months), then go dormant.
So, here's my theory behind the whole proposal: In the current incubator,
people quickly create a bunch of articles on topics that interest them,
sometimes with some boilerplate (cities, countries, animals), but but then
they get tired of the prefixes, the outdated translation techniques, the
weird searching, the missing templates, etc., and give up. Perhaps with a
single wiki these difficulties will be alleviated. I know it sounds a bit
too optimistic, but at least I want to get rid of these most glaring and
arbitrary difficulties, with the hope that it will help people remain
You may be right. I just don't know. Do we have feedback saying so? Or is
this just everyone's gut instinct. (Mind you, I can't possibly say I
Observing people in real life editing in Incubator, many times. In
particular, in Kabardian, Adyghe, Fon, and Dinka, with which I've had a
And a few days ago there was a presentation at Wikimania that makes pretty
much the same complaints:
That said, this approach doesn't solve all the problems you describe. In
particular, this won't automatically create basic templates and modules,
Yes. I'm working on that in a separate initiative. It's complicated, but
And at the end of the day, contributors to new tests still have to write
or translate pages.
Of course, as they do in usual wikis. It's not without issues, but at
least it will have proper search, Wikidata, and Content Translation, and no
Yes, I tend to think that we should allow to
create new subdomains for
*eligible* languages right away, so that all of them will get equal
treatment as early as possible, from the very first page.
In order to do this, then, a few things would have to happen in fairly
short order, once we're ready to approach the problem like that.
- The "Requests for new languages" system on Meta will have to have
teeth, and to be the arbiter for whether a project is (a) eligible for an
incubation subdomain, (b)(interim, at least) should start on Incubator, or
(c) is not eligible. IF THAT IS TO BE MEANINGFUL, I NEED LANGCOM MEMBERS TO
RESPOND TO MY SUBMISSIONS ON SUCH MATTERS, or to go to Meta and mark
projects eligible themselves. I appreciate that people are generally
allowing me to call those shots right now, but since just about anyone can
start a test project on Incubator, the stakes on decisions about
aren't all that high right now. The stakes will become higher under this
Yes, this is pretty obvious.
I do envision that the incubator wiki creation will a mostly automatic
process. There is no good reason for it to require any manual intervention
from Ops engineer, as it happens now. There should be a simple form
somewhere on one of our other wikis, probably Meta or
, where one will have to fill project family (pedia, voyage, etc.),
language code, autonym, text direction, logo file name—and push a button.
The interesting question is who should have the permission to fill this
form and push the button. My immediate thought is "language committee
members", of course, but other ideas are welcome.
- FWIW, in clearing the backlog at RFL, we're almost to the end of
requests dating to 2012 or earlier, and have addressed almost all of the
2017 and 2018 requests (except those in the last month or so).
Have I mentioned how much do I appreciate what you do there? It's truly
wonderful that you are taking care of this backlog.
Langcom mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
Subject: Digest Footer
Langcom mailing list
End of Langcom Digest, Vol 58, Issue 16