Hmm. This is essentially "skip the creation of incubator wikis and instead just start them immediately", with some policy changes about what would be considered "a wiki". There's no real technical blocker at all, AFAICS.

Creating foo.incubator.wikimedia.org wikis and then moving them, however, would create some exceptional technical issues (renaming wikis is essentially impossible to do without breaking things) and add burdens to all read requests on all other wikis (any new fourth-level domain, and particularly any domain under wikimedia.org, bloats the CORS/etc. headers).

In T228745#5358477, @Jdforrester-WMF wrote:

Hmm. This is essentially "skip the creation of incubator wikis and instead just start them immediately", with some policy changes about what would be considered "a wiki".

Something like that, yes. Of course, I recommend allowing this only for eligible languages, and I'm not suggesting any changes in the requisites for eligibility.

I'm just trying to prevent a situation in which some well-meaning people will get a domain created, then find that maintaining it requires more work than they thought it does, and abandon it. This already happened with dozens of languages, and there should be a policy for easier deletion or downgrading. The downgrading can even be only on the level of policy, for example "no local admins".

As far as I'm concerned, there should be as few differences between an "incubator" and a usual wiki as possible, except the possibility of speedier deletion or archival. In theory, this is also a matter of policy, but deletion happens so rarely now that the technical preparedness for this could possibly be improved. (There were very few deletions in the whole history of the WMF: I can only recall Tokipona, Klingon, Siberian, and Moldovan, and there are a few locked wikis, such as Afar and Yi.)

There's no real technical blocker at all, AFAICS.

In theory—yes, because that's how wikis are already created now. In practice, however, it sometimes takes many weeks to create a wiki, and there are issues even after creation: no Wikidata, broken search, etc. And this brings us back to T158730.

Creating foo.incubator.wikimedia.org wikis and then moving them, however, would create some exceptional technical issues (renaming wikis is essentially impossible to do without breaking things) and add burdens to all read requests on all other wikis (any new fourth-level domain, and particularly any domain under wikimedia.org, bloats the CORS/etc. headers).

No problem. The domain name doesn't have to be different, as I noted in the task description.

Suggest the domain be languagecode.wpincubator.org so its clear its not a full functioning wikipedia it would also force the focus to be on one project rather than spread effort to multiple projects

Make it so that IP's cant edit no exception, again as a space to deliver viable projects to create a new language it already necessitates that there is the interest and support.

Incubator can be a site option with language code on WikiData making easy for a bot to run the change to the project when it happens... or remain if the alternative is to archive the site and prevent editing

In T228745#5358477, @Jdforrester-WMF wrote:

Creating foo.incubator.wikimedia.org wikis and then moving them, however, would create some exceptional technical issues (renaming wikis is essentially impossible to do without breaking things) and add burdens to all read requests on all other wikis (any new fourth-level domain, and particularly any domain under wikimedia.org, bloats the CORS/etc. headers).

Isn't the hardest part about this renaming the databases? The databases could have the "proper" names from the beginning, and then the URLs could be changed later on if/when they're approved? I'm probably oversimplifying things though, but you get what I mean. @Gnangarra's suggestion of using a new domain like wpincubator.org would avoid the burden on wikimedia.org at least.

Well, wmincubator.org, but fine.

Interesting question whether or not to allow IPs. Are we thinking that all incubation projects start off this way, or are we thinking that they still start in "the" Incubator, but as soon as there is some real movement they get one of these incubation spaces. I'm thinking that if all incubation projects start off this way, it will be hard for us to tell IPs "no", since that's been a fundamental "right" ever since we started. If projects start in "the" Incubator and then move, then there's more of a justification to allow the projects in the "middle" space to keep IPs out.

Some discussion about it at T238255: Unconference: How can we automate new wiki creation.

Some parts are really important because we (working on the incubator) feel their importance. For example, that no import can be done from Wikidata is a big hinder for many people, and could have made things much easier.
Also, categories and other technical matters are definitely not obvious for newcomers who will write in the incubator, so anything helping in simplifying them (as suggested in this thread) would be great!

In T228745#6298967, @Anass_Sedrati wrote:

Some parts are really important because we (working on the incubator) feel their importance. For example, that no import can be done from Wikidata is a big hinder for many people, and could have made things much easier.
Also, categories and other technical matters are definitely not obvious for newcomers who will write in the incubator, so anything helping in simplifying them (as suggested in this thread) would be great!

Not a solution in general, but for categories I've requested that Template:Category be created, which I will then fill in as a helper so that {{category|Foo}} results in the correctly namespaces category being added.

I dont see not allowing IP's as a big issue, especially if we are using a different domain name technically ts easy enough to deny users who arent logged in. Even well meaning experienced contributors can cause significant issues

This is balanced against the impact on developing a community, and maintaining it. The current system adds complexity to wikicoding which hinders people and makes long term retention harder. The Foundation recognised the wikicoding hindrance and developed Visual Editor, that purpose of building in the incubator is to demonstrate a community and interest in the language yet the wikicoding in the incubator is the biggest hindrance to that.

By having the unique domain we can bring in Wikidata infoboxes, import already existing templates from other projects with minimal changes, and we can develop category structures. All of these build a communities skill set from day one rather than relying on one or two persons doing a lot of back ground maintenance. Theres also the possibility to look at language links to related languages, ie dominant colonial languages, neighboring languages

I would agree that a simple domain wmincubator.org is best way forward. My suggestion is <lang_code>-<project_code>.wmincubator.org. For example: hil-wp.wmincubator.org or pag-wt.wmincubator.org. Once done, I can work on infoboxes, tables and charts extracted/ queried from wikidata. This also make capacity building & outreach activities easier with one standard process. Under the current environment, you have to teach new users about prefixes (links, categories, creation of new pages, etc) and then teach them again editing without prefixes once the project is hatched/ graduated from the incubator.

Having a separate domain is indeed a good idea, but only if it's not too difficult technically.

In T228745#6707963, @Exec8 wrote:

I would agree that a simple domain wmincubator.org is best way forward. My suggestion is <lang_code>-<project_code>.wmincubator.org. For example: hil-wp.wmincubator.org or pag-wt.wmincubator.org. Once done, I can work on infoboxes, tables and charts extracted/ queried from wikidata. This also make capacity building & outreach activities easier with one standard process. Under the current environment, you have to teach new users about prefixes (links, categories, creation of new pages, etc) and then teach them again editing without prefixes once the project is hatched/ graduated from the incubator.

This is a good way forward,

In T228745#6707963, @Exec8 wrote:

I would agree that a simple domain wmincubator.org is best way forward. My suggestion is <lang_code>-<project_code>.wmincubator.org. For example: hil-wp.wmincubator.org or pag-wt.wmincubator.org. Once done, I can work on infoboxes, tables and charts extracted/ queried from wikidata. This also make capacity building & outreach activities easier with one standard process. Under the current environment, you have to teach new users about prefixes (links, categories, creation of new pages, etc) and then teach them again editing without prefixes once the project is hatched/ graduated from the incubator.

This is a great idea. It may even be shorter. wmi.org domain is free now.

In T228745#6707963, @Exec8 wrote:

I would agree that a simple domain wmincubator.org is best way forward. My suggestion is <lang_code>-<project_code>.wmincubator.org. For example: hil-wp.wmincubator.org or pag-wt.wmincubator.org. Once done, I can work on infoboxes, tables and charts extracted/ queried from wikidata. This also make capacity building & outreach activities easier with one standard process. Under the current environment, you have to teach new users about prefixes (links, categories, creation of new pages, etc) and then teach them again editing without prefixes once the project is hatched/ graduated from the incubator.

Excellent idea! This will make it a lot easier for new and existing editors to incubating new projects.

In T228745#6707963, @Exec8 wrote:

I would agree that a simple domain wmincubator.org is best way forward. My suggestion is <lang_code>-<project_code>.wmincubator.org. For example: hil-wp.wmincubator.org or pag-wt.wmincubator.org.

Would this also prevent the secret incubator project creators from creating new projects that should never exist being or with non-existent language codes? Right now it's possible to create new incubator projects without ever receiving approval and often they're just stumbled upon at some point in time.

Once done, I can work on infoboxes, tables and charts extracted/ queried from wikidata. This also make capacity building & outreach activities easier with one standard process. Under the current environment, you have to teach new users about prefixes (links, categories, creation of new pages, etc) and then teach them again editing without prefixes once the project is hatched/ graduated from the incubator.

As someone working on a recently hatched Wikipedia project (smn), these are two major points. We've wasted a lot of time having to fix stuff that worked on the incubator and not the actual Wikipedia itself. And I'd love to see infoboxes, tables, etc using wd queries since it would free us up from having to update things like the population of every village, province, country, etc. every year.

If we do decide to go forward with this, I suggest it's not a good idea to automatically transfer every incubator project wholesale to the new domain, particularly in light of the Scots wp scandal, etc.

I also agree with Gnangarra's idea of not letting IP addresses edit.

In T228745#6710684, @Yupik wrote:

In T228745#6707963, @Exec8 wrote:

I would agree that a simple domain wmincubator.org is best way forward. My suggestion is <lang_code>-<project_code>.wmincubator.org. For example: hil-wp.wmincubator.org or pag-wt.wmincubator.org.

Would this also prevent the secret incubator project creators from creating new projects that should never exist being or with non-existent language codes? Right now it's possible to create new incubator projects without ever receiving approval and often they're just stumbled upon at some point in time.

Non-existent language codes: definitely not. A language code is part of the eligibility requirements, and I specifically don't suggest changing them. I updated the description of this task to say this explicitly.

There's the question of who will have the permission to create a wiki in this process. In the current Incubator, it's pretty much anybody, and there are almost no checks. The software kind of checks that the code is valid, but even that is very lax.

In what I propose, it's probably OK not to allow everyone to do it. At the moment, it's a thing that happens several times a year. I hope that once we have the infrastructure, it will become more frequent, but it probably won't become a thing that happens several times a day. So it's probably OK if the permission to do this remains with a small group, for example Language committee members, Stewards, or Global admins. This is not 100% bulletproof, but it will likely filter out the most obvious hoaxes and languages that aren't likely to succeed.

Once done, I can work on infoboxes, tables and charts extracted/ queried from wikidata. This also make capacity building & outreach activities easier with one standard process. Under the current environment, you have to teach new users about prefixes (links, categories, creation of new pages, etc) and then teach them again editing without prefixes once the project is hatched/ graduated from the incubator.

As someone working on a recently hatched Wikipedia project (smn), these are two major points. We've wasted a lot of time having to fix stuff that worked on the incubator and not the actual Wikipedia itself. And I'd love to see infoboxes, tables, etc using wd queries since it would free us up from having to update things like the population of every village, province, country, etc. every year.

A new incubator will make this easier, but ideally, this will also require a global templates repository ;)

If we do decide to go forward with this, I suggest it's not a good idea to automatically transfer every incubator project wholesale to the new domain, particularly in light of the Scots wp scandal, etc.

No, not wholesale. One by one and manually.

I also agree with Gnangarra's idea of not letting IP addresses edit.

I'm inclined to the side of being permissive and allowing this, because by default I want to stick to the "anyone can edit" ethos as much as possible, and as far as I know, IP editing is not an exceptional problem in the current Incubator or in the small wikis. It's really not a strong opinion, however. Most importantly, from the technical point of view, it's a trivial thing to enable and disable.

and this must be easy to rename to a standard domain (languagecode.wikipedia.org) once the Language committee grants a full approval. And again, it's OK if it's just languagecode.wikipedia.org right from the start as long as patroling for vandalism works reasonably well.

Not really. There are multiple over-a-decade-old request on changing language code of a wiki and only one get achieved, and that one achieved renaming caused so much problems that all other requests are still not doable after they have been requested for over a decade
The T172035 have to be solved first

In T228745#6707963, @Exec8 wrote:

I would agree that a simple domain wmincubator.org is best way forward. My suggestion is <lang_code>-<project_code>.wmincubator.org. For example: hil-wp.wmincubator.org or pag-wt.wmincubator.org. Once done, I can work on infoboxes, tables and charts extracted/ queried from wikidata. This also make capacity building & outreach activities easier with one standard process. Under the current environment, you have to teach new users about prefixes (links, categories, creation of new pages, etc) and then teach them again editing without prefixes once the project is hatched/ graduated from the incubator.

+1 this. Having observed several (mostly successful) efforts to get Indonesian languages projects out of Incubator, this could really be helpful.

In T228745#6707963, @Exec8 wrote:

I would agree that a simple domain wmincubator.org is best way forward. My suggestion is <lang_code>-<project_code>.wmincubator.org. For example: hil-wp.wmincubator.org or pag-wt.wmincubator.org. Once done, I can work on infoboxes, tables and charts extracted/ queried from wikidata. This also make capacity building & outreach activities easier with one standard process. Under the current environment, you have to teach new users about prefixes (links, categories, creation of new pages, etc) and then teach them again editing without prefixes once the project is hatched/ graduated from the incubator.

Yes, this is helpful. This would ease the burden of having to make adjustments for newbie editors. It is beneficial both for the ones who is teaching the editing process and the ones being taught. It is a fact that sometimes those who have the full grasp of the language (ex. small languages such as Central Bikol, Rinconada Bikol), are not so inclined in technicalities like this but it is them who pursues the job of editing. The point is always to make things much simpler both for the developers and the end users.

What happens when a production wiki gets closed? Currently the flow includes importing its content back to incubator, having the main wiki only editable by stewards, and then subsequently reimport of the updated pages when the wiki gets to be reopened, IIRC. What would the flow look like if we have separate incubator instances?

In T228745#6712312, @Base wrote:

What happens when a production wiki gets closed? Currently the flow includes importing its content back to incubator, having the main wiki only editable by stewards, and then subsequently reimport of the updated pages when the wiki gets to be reopened, IIRC. What would the flow look like if we have separate incubator instances?

The simplest, immediate answer is that the current Incubator can remain open, and we can continue doing the same thing until we can figure out something better.

The more complicated answer is that we need to figure out something better about project closing in general, but it should be a separate discussion.

In T228745#6712312, @Base wrote:

What happens when a production wiki gets closed? Currently the flow includes importing its content back to incubator, having the main wiki only editable by stewards, and then subsequently reimport of the updated pages when the wiki gets to be reopened, IIRC. What would the flow look like if we have separate incubator instances?

Disable editing to all but stewards/language committee, other than that leave the efforts visable. At some point in the future should(when) a new group come a long wanting to restart efforts then they could apply for it to be reopened for editing. Every ISO language code exists because the language does, there will other opportunities to build on what was started. In the mean time we keep the good faith established with any third parties being able to still link back to the original pages.

I think overall these requirements make a lot of sense.

In fact, I would go a step further and say that most of these are bare-minimum criteria for keeping Incubator at all in its current form as a Foundation-hosted project. If these needs can't be funded, I think we should seriously consider shutting down Incubator in its current form as it is a significant burden on the software and our infrastructure due to trying very hard to do something that both our backend software and the frontend interface are clearly not meant to support. And as such, it regularly breaks itself and/or other areas of our projects, and even when it isnt' broken, there are endless ways in which the current Incubator hybrid doesn't work as expected due to conflicting feature behaviours. Overall it is in my opinion far below any reasonable standard of user experience.

A few minor points on the proposed implementation details, most of which others have mentioned already and I agree with:

• the new Incubuator family is perhaps best not placed under a third-level domain like *.incubator.wikipedia.org because doing so would introduce new domain patterns and technical requirements that we we have to support at every level of our infrastructure just for Incubator. This doesn't seem like a worthwhile thing to maintain and invest in indefinitely, and indeed is trivially avoided by using a pattern like incubator-*.wikipedia.org instead.
• placing the Incubator family anywhere under wikipedia.org might indeed be best avoided for reasons of branding and trust, depending on what level of trust and official-ness we think this content should have on public display to the world. Also kee in mind that Mozilla and Google are both moving towards emphasing only the first-level domain (e.g. wikipedia.org), with the subdomain and incubator prefix limited to a more tech-savvy audience that concerns itself with URLs. If we want to retain clear and unambigious affiliation with "Wikipedia", without a confusing domain or arguably incorrect trust levels, we could use something like wikipediaincubator.org.

this must be easy to rename to a standard domain (languagecode.wikipedia.org) once the Language committee grants a full approval.

I think the overall objective here of having each incubation project be its own "wiki" (and still retain most of the benefits we have today from shared wiki, with unified RCFeed/patrolling experiences) – is large enough to keep us busy for a while and reap big and meaningul benefits to all participants.

Easy renaming or moving of wikis would certainly be great, but I think is perhaps better omitted from this proposal as that's fairly complex and not something I think would very directly impact Incubator. It's mostly an implementation detail that we're pretty good at hiding, as far as I know? What participants care about, I think, is for the project to be promoted and recognised as a Wikipedia language project with its content, structure and identies preserved. Our approach of creating a new wiki, and using export/import with CentralAuth, accomplish that sufficiently, I think? If not, perhaps some of the underlying issues or shortcomings with that can be laid out and added to the proposal to mitigate in some way.

it's just languagecode.wikipedia.org right from the start as long as patroling for vandalism works reasonably well.

In addition to the concerns above, I think this would be incompatible with "The domain must be temporary" and the unified RCFeed/patrolling expectations. Once a Wikipedia project by this domain exists, I think there is significant amounts of first-party and third-party infrastructure out there in the world that expects such wiki to act a certain way in terms of monitoring, and for that wiki to remain in the long-term. Breaking that expectation would I think likely indefinitely cause confusion and breakage for little to no benefit.

In T228745#6712680, @Krinkle wrote:

I think overall these requirements make a lot of sense.

Thanks a lot for this comment!

• placing the Incubator family anywhere under wikipedia.org might indeed be best avoided for reasons of branding and trust, depending on what level of trust and official-ness we think this content should have on public display to the world.

Indeed, branding is important. I mention something similar in my video presentation about this, especially at 15:30 and 17:50.

Also keeping in that that Mozilla and Google are both drifting towards emphasing only the first-level domain (e.g. wikipedia.org), with the subdomain and incubator prefix limited to a more tech-savvy audience that concerns itself with URLs. If we want to retain clear and unambigious affiliation with "Wikipedia", without a confusing domain or arguably incorrect trust levels, we could use something wikipediaincubator.org.

Sounds OK to me. It can even be more generic and less directly associated with Wikipedia, e.g. testwikiencyclopedia.org. It's a question for branding experts.

this must be easy to rename to a standard domain (languagecode.wikipedia.org) once the Language committee grants a full approval.

I think the overall objective here of having each incubation project be its own "wiki" (and still retain most of the benefits we have today from shared wiki, with unified RCFeed/patrolling experiences) – is large enough to keep us busy for a while and reap big and meaningul benefits to all participants.

Easy renaming or moving of wikis would certainly be great, but I think is perhaps better omitted from this proposal as that's fairly complex and not something I think would very directly impact Incubator. It's mostly an implementation detail that we're pretty good at hiding, as far as I know? What participants care about, I think, is for the project to be promoted and recognised as a Wikipedia language project with its content, structure and identies preserved. Our approach of creating a new wiki, and using export/import with CentralAuth, accomplish that sufficiently, I think? If not, perhaps some of the underlying issues or shortcomings with that can be laid out and added to the proposal to mitigate in some way.

It doesn't have to be a smart rename. If we take a fictional language called "Syldavian", with the made-up code syv, it can be something like this:
Incubator stage:

• Create syv.wikipediaincubator.org.
• Ensure that the same default version of core MediaWiki and extensions are loaded and regularly updated in the same train process.
• Ensure that it's connected to the CentralAuth system and can have the same user accounts as en.wikipedia.org, etc.
• Ensure that it can get data from Wikidata and display sitelinks as interlanguage links.
• Ensure that it you can translate articles from Wikipedia in other languages into it using Content Translation (requires some slightly non-trivial changes in the ContentTranslation extension, but definitely doable).
• Ensure that you can use it in Wikipedia Android and iOS apps (this is an actual request from people who write in Incubators in several languages).
• Ensure that the search box works (it's also not obvious and sometimes broken in new projects).
• Ensure that it appears in statistics tools: Pageviews, Wikistats, Turnilo, Superset, etc.

Graduation:

• Language committee approves it; this is a community process and not a technical function.
• Lock syv.wikipediaincubator.org for editing. (Announce it first...)
• Save a syv.wikipediaincubator.org dump.
• Create syv.wikipedia.org.
• Import the dump into syv.wikipedia.org.
• Allow editing.
• Ensure that Wikidata sitelinks from syv.wikipedia and to syv.wikipedia still work.
• Redirect all links that point to syv.wikipediaincubator.org to syv.wikipedia.org.

A few hours or even days without editing is not such a big deal, if that's what it takes. Does it sound doable?

Just a quick note about the fact that Incubator might serve also other projects than Wikipedia. :) For the rest, I am strongly in favour of this proposal and I really loved Krinkle's comment, which I found particularly on point.

In T228745#6714442, @Amire80 wrote:

In T228745#6712680, @Krinkle wrote:

I think overall these requirements make a lot of sense.

Thanks a lot for this comment!

• placing the Incubator family anywhere under wikipedia.org might indeed be best avoided for reasons of branding and trust, depending on what level of trust and official-ness we think this content should have on public display to the world.

Indeed, branding is important. I mention something similar in my video presentation about this, especially at 15:30 and 17:50.

Also keeping in that that Mozilla and Google are both drifting towards emphasing only the first-level domain (e.g. wikipedia.org), with the subdomain and incubator prefix limited to a more tech-savvy audience that concerns itself with URLs. If we want to retain clear and unambigious affiliation with "Wikipedia", without a confusing domain or arguably incorrect trust levels, we could use something wikipediaincubator.org.

Sounds OK to me. It can even be more generic and less directly associated with Wikipedia, e.g. testwikiencyclopedia.org. It's a question for branding experts.

this must be easy to rename to a standard domain (languagecode.wikipedia.org) once the Language committee grants a full approval.

I think the overall objective here of having each incubation project be its own "wiki" (and still retain most of the benefits we have today from shared wiki, with unified RCFeed/patrolling experiences) – is large enough to keep us busy for a while and reap big and meaningul benefits to all participants.

Easy renaming or moving of wikis would certainly be great, but I think is perhaps better omitted from this proposal as that's fairly complex and not something I think would very directly impact Incubator. It's mostly an implementation detail that we're pretty good at hiding, as far as I know? What participants care about, I think, is for the project to be promoted and recognised as a Wikipedia language project with its content, structure and identies preserved. Our approach of creating a new wiki, and using export/import with CentralAuth, accomplish that sufficiently, I think? If not, perhaps some of the underlying issues or shortcomings with that can be laid out and added to the proposal to mitigate in some way.

It doesn't have to be a smart rename. If we take a fictional language called "Syldavian", with the made-up code syv, it can be something like this:
Incubator stage:

• Create syv.wikipediaincubator.org.
• Ensure that the same default version of core MediaWiki and extensions are loaded and regularly updated in the same train process.
• Ensure that it's connected to the CentralAuth system and can have the same user accounts as en.wikipedia.org, etc.
• Ensure that it can get data from Wikidata and display sitelinks as interlanguage links.
• Ensure that it you can translate articles from Wikipedia in other languages into it using Content Translation (requires some slightly non-trivial changes in the ContentTranslation extension, but definitely doable).
• Ensure that you can use it in Wikipedia Android and iOS apps (this is an actual request from people who write in Incubators in several languages).
• Ensure that the search box works (it's also not obvious and sometimes broken in new projects).
• Ensure that it appears in statistics tools: Pageviews, Wikistats, Turnilo, Superset, etc.

Graduation:

• Language committee approves it; this is a community process and not a technical function.
• Lock syv.wikipediaincubator.org for editing. (Announce it first...)
• Save a syv.wikipediaincubator.org dump.
• Create syv.wikipedia.org.
• Import the dump into syv.wikipedia.org.
• Allow editing.
• Ensure that Wikidata sitelinks from syv.wikipedia and to syv.wikipedia still work.
• Redirect all links that point to syv.wikipediaincubator.org to syv.wikipedia.org.

A few hours or even days without editing is not such a big deal, if that's what it takes. Does it sound doable?

This is better. Just add a hyphen and the project code after the language code like syv-wp.wikincubator.org (wikipedia) syv-wt.wikincubator.org (wiktionary), and so on and so forth.

If visual editor can be added, the better.

This applies to incubator projects that have a total of at least 10kB in total size and 10 unique pages and was approved as an incubator project by the language committee. This is regardless if the incubator project is 4 days or 14 years inactive/ dormant/ active in incubator.

It doesn't have to be a smart rename. If we take a fictional language called "Syldavian", with the made-up code syv, it can be something like this:
Incubator stage:

• Create syv.wikipediaincubator.org.
• Ensure that the same default version of core MediaWiki and extensions are loaded and regularly updated in the same train process.
• Ensure that it's connected to the CentralAuth system and can have the same user accounts as en.wikipedia.org, etc.
• Ensure that it can get data from Wikidata and display sitelinks as interlanguage links.
• Ensure that it you can translate articles from Wikipedia in other languages into it using Content Translation (requires some slightly non-trivial changes in the ContentTranslation extension, but definitely doable).
• Ensure that you can use it in Wikipedia Android and iOS apps (this is an actual request from people who write in Incubators in several languages).
• Ensure that the search box works (it's also not obvious and sometimes broken in new projects).
• Ensure that it appears in statistics tools: Pageviews, Wikistats, Turnilo, Superset, etc.

Inactivity

• //language committee function via technical monitoring
• Lock syv.wikipediaincubator.org for editing. (Announce it first...)
• reopen to restart, keeping what was created earlier

Graduation:

• Language committee approves it; this is a community process and not a technical function.
• Lock syv.wikipediaincubator.org for editing. (Announce it first...)

....

In T228745#6714448, @Exec8 wrote:

This applies to incubator projects that have a total of at least 10kB in total size and 10 unique pages and was approved as an incubator project by the language committee. This is regardless if the incubator project is 4 days or 14 years inactive/ dormant/ active in incubator.

I'm not sure where are these numbers coming from :)

If you're talking about migrating from the current incubator to the new proposed sites, it's unlikely that inactive sites with just 10 pages will be migrated. Certainly not among the first ones. It's a question of language committee policy details, but I imagine that the first sites to migrate from the current incubator to the new autonomous wikis will be those that have some actual activity. The abandoned Incubators with few pages and no editors will probably wait until people who know these languages come to revive them.

In T228745#6714459, @Amire80 wrote:

In T228745#6714448, @Exec8 wrote:

This applies to incubator projects that have a total of at least 10kB in total size and 10 unique pages and was approved as an incubator project by the language committee. This is regardless if the incubator project is 4 days or 14 years inactive/ dormant/ active in incubator.

I'm not sure where are these numbers coming from :)

If you're talking about migrating from the current incubator to the new proposed sites, it's unlikely that inactive sites with just 10 pages will be migrated. Certainly not among the first ones. It's a question of language committee policy details, but I imagine that the first sites to migrate from the current incubator to the new autonomous wikis will be those that have some actual activity. The abandoned Incubators with few pages and no editors will probably wait until people who know these languages come to revive them.

For example, Hiligaynon Wikipedia, https://incubator.wikimedia.org/wiki/Category:Wp/hil . It is 1800+ number of articles. Much activity happened in 2014 by yours truly but got dormant again.

I dont have anything else to add to this project except infoboxes, and wikidata populated templates. I wish not to pursue this while the prefixes are still in force.

Hiligaynon wikipedia's byte size and number of articles, may target potential 7 million Hiligaynon users/readers. Though I believe hil wp is not yet qualified to graduate, it best fit in this proposed higher level or "purgatory" incubator.

In T228745#6714509, @Exec8 wrote:

In T228745#6714459, @Amire80 wrote:

In T228745#6714448, @Exec8 wrote:

This applies to incubator projects that have a total of at least 10kB in total size and 10 unique pages and was approved as an incubator project by the language committee. This is regardless if the incubator project is 4 days or 14 years inactive/ dormant/ active in incubator.

I'm not sure where are these numbers coming from :)

If you're talking about migrating from the current incubator to the new proposed sites, it's unlikely that inactive sites with just 10 pages will be migrated. Certainly not among the first ones. It's a question of language committee policy details, but I imagine that the first sites to migrate from the current incubator to the new autonomous wikis will be those that have some actual activity. The abandoned Incubators with few pages and no editors will probably wait until people who know these languages come to revive them.

For example, Hiligaynon Wikipedia, https://incubator.wikimedia.org/wiki/Category:Wp/hil . It is 1800+ number of articles. Much activity happened in 2014 by yours truly but got dormant again.

This is a very good number of articles.

I dont have anything else to add to this project except infoboxes, and wikidata populated templates. I wish not to pursue this while the prefixes are still in force.

Infoboxes and Wikidata are really not a requirement, as far as the Language committee goes. The real main requirements are having multiple native speakers actively writing in the language in the Incubator continuously and 100% localization of the most used MediaWiki messages (looking at the current localization statistics, you can finish this in a day or two).

The perception that Infoboxes and Wikidata are "required" is, however, a sign that Wikipedians expect these useful things and that it is indeed bad that the current Incubator doesn't provide them. (Also, we need a Global templates repository, so that you won't have to work at all on importing the templates' code, but just localize their strings. But that's a separate issue.)

Hiligaynon wikipedia's byte size and number of articles, may target potential 7 million Hiligaynon users/readers. Though I believe hil wp is not yet qualified to graduate, it best fit in this proposed higher level or "purgatory" incubator.

It's "purgatory" in a positive sense, I presume :)

This is a living language with many speakers and there are people who know it and know how to edit Wikipedia, so graduating is not supposed to be very hard.