Wikimedia Hackathon 2024 (chat via Telegram at https://t.me/wmhacks) is ongoing. I hope this be given some attention and collaboratively discuss a path to a resolution.

Move "Scholarships/Selection Process" to "2022:Scholarships/Selection Process"
Move "Scholarships/FAQ" to "2020:Scholarships/FAQ"

Required tasks:
Move Wikimania page "Scholarship" to "2022:Scholarship"
Move Wikimania page "Program" to "2022:Program"
Notify Exec8, Ameisenigel and Robertsky completion of the move.

I hope it will be ready on January 15 to coincide with the en wiki anniversary.

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.

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?

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.

There are still issues:

It will be ok. The old list will then must be deactivated to avoid public confusion having two mailing lists. If name "WikimediaMY" can't be reused, "Wikimedia_Malaysia" will be used instead.

You can make me a co-admin/ secondary admin. My email address is xxxxxx.