Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
“We're living in pieces,
I want to live in peace.” – T. Moore
2018-07-27 18:29 GMT+03:00 Steven White <Koala19890(a)hotmail.com>om>:
OWTB makes some good points.
- There needs to be a consultation with the Incubator admins, and then
there needs to be at least one general community discussion. Concerning
Incubator admins, three are here (MF-Warburg, Robin and me). Three others
are at least reasonably active on Incubator (including OWTB, who is very
active), another is responsive to specific requests, and two others haven't
made an edit or had a logged event in over a year. Do we want that
consultation to be on-wiki (public)? Or should we invite any/all of them to
have temporary rights to this list, and discuss it semi-privately here
As I already mentioned, there will be a consultation with the current
Incubator admins, of course.
- I don't know if the community discussion should be on Incubator (and
advertised at Meta [and Beta]), on Meta (and advertised on Incubator [and
Beta]), or if there should be two. And when do we start it? Thoughts?
Probably in the Incubator first, and then in a wider forum.
As far as substantive issues go, there are really two separate issues (or
constituencies) that partially overlap that are being conflated here.
- I am strongly in favor of moving the strongest, most active
test projects into incubation subdomains. I think that's a great idea.
Giving those projects more complete functionality, especially access to
WD, and getting rid of Incubator peculiarities like prefixes, is
all certainly worthwhile for them. None of the downsides I'm going to point
out below really apply to them. So if we can manage an admin interface that
continues to let us help them manage spam, bots, etc., and if there are no
more than about 20 of them, I think this would be fantastic.
The other issue (which OWTB doesn't mention) is the creation of brand new
test projects. The idea is to make it easier for new test wikis, to give
them all of the associated functionality that full projects have, and that without
all of Incubator's peculiarities.
Yes, this is definitely part of my proposal: not only the current active
projects, but also new ones.
And in principle, that's a great idea. Still, I
think there are also a lot
of potential problems with this.
- How do we decide what constitutes a serious enough request to press
the button? For "subsequent projects in existing languages", it would be
easy enough to require some activity history in the existing wiki(s). But
for new languages, how do you do that? Yes, deciding the language is
"eligible" is a necessary condition. But sufficient?
- Even now, there continue to be LTA's coming and creating new
requests that are effectively spurious. They're valid on their
face—language is eligible—but requesters don't speak the language, and no
community exists. (It happens less now that I am patrolling there, but it
still happens.) For now, at minimum we wait until there are people around
who create some content before saying, "eligible". That at least
demonstrates that a couple of people are present and actually creating
content that appears to be in the right language.
Known LTAs (that's "long-term abusers", right?) should be speedily
I'd even consider going as far as *speedily deleting* the proposals they
make, and not only rejecting them. If they persist in archives, they may
discourage serious people who propose the same language in the future.
- I am extremely worried that this will turn into the "bad old
days", where just about anyone could create a project, and many fell into
disuse (and/or were never serious). Do we want "The Wild West" again?
Of course not.
We'll need some reasonable proof that the person who makes the proposal
actually speaks the language or works with people who do. (There are more
and more of these projects lately, for example the Dinka one and the
Taiwanese languages, some of which appear to be close to graduating from
I'm trying to address the "falling into disuse" issue in the following part
of my proposal: "The domain must be temporary, for example for a year. It
must be easy to destroy the domain without a difficult closing process if
it proves to be inactive, spammy, or too prone to vandalism." This may be a
bit naive, however, so a more detailed proposal is welcome. (But please
read the full thing at https://phabricator.wikimedia.org/T165585
In the meanwhile, I think there are three things that
we can do right
now to see if we can alleviate some of the current editing issues on
Incubator right now:
1. Turn on the "Add Prefix" gadget by default. It doesn't make all the
prefix-related problems go away, but it simplifies them quite a lot. Just
about everyone except sysops (and similar people who do a lot of
maintenance) ought to have this on. [I can open a discussion on Incubator
about this today, and trigger it in seven days unless there are objections.]
I don't think that I object to this, but please be sure that it doesn't
make things more complicated for newbies of various kinds. Pretty much
everything about Incubator prefixes is awful and making them smarter *may*
make them more awful ¯\_(ツ)_/¯
1. Use the authority of LangCom to set a priority to get some kind of
access to Wikidata turned on right away. I think a lot of what is holding
that up is the challenge of multiple iw links from Incubator. So let's
simply not allow/demand/require that for now. Most of the capability
currently exists somewhere within the WMF world to allow *Incubator's *pages
(a) to call information from Wikidata into things like infoboxes, and even
(b) to produce an iw list to appear on our pages. Much of that capability
includes the possibility of calling information from Qxxx even when the
page you're editing is associated with Qyyy; all you have to do is add
"|q=xxx" as a parameter. So we simply require such a parameter. Access to
WD would help a lot.
Good idea. If it's technically feasible, I'm all for it. Do you want to
start a Phab task for it?
1. Less important, but useful: Finish fixing some of the problems with
Incubator extension (like the default info pages and especially their links
to Wikipedia projects).
Perhaps Robin can help with that?..