The following request for comments
is closed. No consensus at this point in time for action to be taken, with several aspects of this discussion now being out of date or inaccurately reflecting the state of current events. ~riley (talk) 02:39, 17 January 2020 (UTC)
- Moved from Incubator:Reform discussions at 14:02, 6 September 2018 (UTC). StevenJ81 (talk)
This proposal involves 7 things:
- the merger of OldWikisource and BetaWikiversity into Incubator;
- the merger of TranslateWiki into Incubator (and, as a result, TW becoming part of Wikimedia SUL);
- the removal of restrictions on minimal testwiki size or interface translation percentage required to create a new Wikimedia language project;
- the removal of minimum translation amounts for MediaWiki interface languages (allowing any language, no matter how much translation has been completed, to earn a spot as a MediaWiki interface language option in Special:Preferences);
- the removal of language code restrictions, both on Incubator and on TranslateWiki (SIL can't possibly cover everything);
- the removal of the complex new language process;
- and, last but not least, the addition of an extension allowing anyone with a Wikimedia SUL account to press a button on the root page of a test wiki (e.g. Wt/lfn, Wp/avk); when this button is pressed, it tells the Wikimedia servers to start the process to turn that test wiki into a full wiki (database tables, importing, interwiki via Wikidata, etc.)
Lojbanist (talk) 22:31, 22 August 2018 (UTC)
- @Lojbanist: I am 100% in favor of integrating beta.wv but s:mul: can't ever be rolled into Incubator because there are texts which are themselves multilingual. Even if you added mw:Extension:Proofread_Page to Incubator (or whatever the new iteration of Incubator is), unlike all other WMF projects, there are sources that are multilingual (and possibly even non-lingual) that need to remain in a repository that doesn't have a language code. —Justin (koavf)❤T☮C☺M☯ 22:56, 22 August 2018 (UTC)
- I will probably move this discussion to Meta in the near-to-mid-future. This page is really for the Incubator community to discuss the nuts-and-bolts details about how to implement a reform. The proposal you have made reflects an overhaul of the rules that needs to be discussed more broadly on Meta.
- That having been said, I don't think that WMF would be willing to go down this road. While I know you feel frustrated with many of the rules here, let me try to explain why I think that is so, referring to your points when I can:
- (item 1) @Justin is right about Old Wikisource.
- With respect to Beta WV, LangCom may well be willing to address that question later. The recent close of that request on Meta reflected a combination of (i) wanting to wait until any current reform discussion is either implemented or outright rejected before proceeding with this, and (ii) @MF-W's and my lack of time to add this to our workload, since we'd probably be the ones needing to implement. In any event, if the rest of what you propose actually happened, (item 7) could probably be implemented on Beta, also, so the question of whether the remainder of Beta and Incubator ever get merged becomes far less important.
- (item 5) This won't happen, for two interrelated reasons. First, WMF and LangCom really do not want projects fragmented more than they must be. There are two reasons, in turn, for that. (i) On the whole, the more fragmented the projects, the less likely a true NPOV will be established. Just to give one example, if anyone fluent in German living in Germany, Austria, Switzerland, etc. can easily use German Wikipedia, WMF wants them to use German Wikipedia. It doesn't want separate German, Austrian, Swiss, etc. Wikipedias. (Granted, in practice there are some exceptions that exist. Mostly they make a mess, and we wish they didn't.) (ii) Such fragmented projects create duplicative work on infrastructure and core contents, and mean that many contributors would be diverted from focusing on new content creation.
- Second, based on its Mission and Vision, WMF does not think that an absolute free-for-all in terms of languages helps it achieve those ends as well as a managed language process. Part of this has to do with the previous point: A single German Wikipedia helps achieve these ends better than 3–4 substantially identical ones do. Beyond that, WMF feels that creating projects in most historical, extinct or artificial languages (especially artificial literary languages, in the latter case) not only does not help it achieve its goals, but to some extent interferes. (In the whole Klingon thing, WMF didn't feel that Klingon projects would help it disseminate knowledge, and also felt that it would undermine peoples' view of the seriousness of WMF's projects. [Don't argue that point here; I'm just illustrating.])
- There is now a process for otherwise-ineligible languages to get projects approved. Rightly, it requires some effort to get a code first, and rightly, the bar is high. But there is now a possibility, because LangCom agrees at least in principle that SIL will not always get everything right.
- (item 2) Translatewiki is used far more broadly than just in Wikimedia projects. For that reason, it prefers to remain separate. It's a good question whether an OAUTH can be set up for that, though.
- (items 3 and 4, and to some extent 6 and 7): Mid-to-late in the decade of the 2000's, the situation around here was a real Wild West: Effectively anyone could create a new project, in effectively any language. And while many good things came of that, there was also a problem that many of the projects created then were never seriously worked on, and many (often the same ones) turned into spam magnets. The current system is designed in part to encourage new projects while keeping some level of quality control in place. That it hasn't always succeeded in that is at the root of the ongoing reform discussions. But nobody wants to swing totally back the other way.
- (item 6) The problem with this is only partly the complexity of the process; it's also the fact that it's frequently hard to get LangCom to address the process. I became LangCom clerk to try to move this along, and I've had a lot of success at that. But this is still an issue. It's one, though, that I think will improve substantially when I finish cleaning up the process's backlog.
- (items 6 and 7) To a great extent, the aspirational goal is precisely what you suggest: press a button on the root page of a test wiki to start a simple process of creating a new wiki. It differs from your description in only two ways. First, only some people will be able to push that button. However, those people are going to be constrained that if the project is actually eligible for creation, they must push the button; they can't decide not to. Second, the new wiki will go through an incubational period first, so that if contributors decide to walk away without having created much, we don't end up with a lot of mostly-vacant projects.
- Finally: It's easier now than ever for someone not able to create a project within the Wikimedia world to create an encyclopedia or dictionary (or whatever) project on his/her own. We're in the process of moving Incubator Plus from Wikia to Miraheze, where projects will look and feel a lot more like WMF projects than they do now. And both of those Wiki hosts have fairly low requirements for allowing completely new projects to start. The only real downside is that such projects don't get the Wikimedia branding. But WMF owns its branding, and is allowed to set its own rules for it. In every other way, it's easy for someone wanting to create a project in an "ineligible" language to build a project that resembles projects here in every respect.
- In short, I think WMF has a lot of reasons it wouldn't want to go down this road, and few reasons it would want to. But, of course, that's just my opinion. StevenJ81 (talk) 15:27, 23 August 2018 (UTC)
- I would prefer if Incubatorplus was hosted on its own servers, separately from the WMF, Wikia, and Miraheze. Lojbanist (talk) 19:02, 23 August 2018 (UTC)
- Why? Also, how? —Justin (koavf)❤T☮C☺M☯ 00:26, 24 August 2018 (UTC)
- This proposal has a lot of points that are not in the original Phabricator task or the Incubator discussion. These extra points make it too far from the purpose of this page, and a non-starter. StevenJ81 explains why very well and I don't have much to add. --Amir E. Aharoni (talk) 15:45, 26 August 2018 (UTC)
- End of portion moved. StevenJ81 (talk)
- For the second proposal, I would ping maintainers of translatewiki.net: @Nemo bis, Siebrand, Nikerabbit, and Raymond: to see if they agree such merger or not. --Liuxinyu970226 (talk) 11:16, 13 September 2018 (UTC)
- Item number 2 will not happen. In my opinion this RfC is rather inspirational than practical, but I do support further discussion on item number 4 (both on the requirement for new languages, and the export threshold for message groups in translatewiki.net). Here are some links to connect to existing efforts:
- –Nikerabbit (talk) 14:04, 13 September 2018 (UTC)
- @Nikerabbit: I agree #2 will not happen. But what is the chance that pseudo-#2 could happen by creating an OAUTH link? StevenJ81 (talk) 15:26, 13 September 2018 (UTC)
- Using mw:Extension:OAuthAuthentication is theoretically possible, but it is complicated by our custom sign-up process where we give translator rights. –Nikerabbit (talk) 08:40, 14 September 2018 (UTC)
- I think that the extension CreateWiki should be installed if this proposal passes. Znotch190711 (talk) 01:29, 13 August 2019 (UTC)
- 2. No. Translatewiki actually has it's own hosting and as such meta or WMF can't do anything about it. Besides, I actually like translatewiki being seperate, without going into the reasons for that.
- 3. and 4. No. New projects are expected to translate the most used messages. The user interface is always going to be too much based on fallback languages if that is not the case. Any group of users serious about creating a wiki would go through the trouble of completing these tasks.
- 5. and 6. No. Allready mitigated by the recent change to the Language proposal policy at 13 June 2019.
- 7. No. The underlying technical change is bigger than you think. I can't imagine any senior wmf developer signing up on this, meaning it will never be done. Again, if people can't bother making an effort to create the wiki, then they can't be expected to create one out of thin air.--Snaevar (talk) 18:00, 19 August 2019 (UTC)