Requests for Comment/Premium offerings (in-house proposal)


 * Summary: An alternative to Requests for Comment/Premium offerings, this proposal puts forth the seeds and basis of Miraheze premium wikis which would be part of Miraheze Limited, the current nonprofit company headquartered on the United Kingdom, without signing a contract with an extraneous private entity.

Institutional and financial basis

 * Miraheze Premium will only be a service provided by Miraheze Limited. The service is available to monthly donors over a certain threshold.
 * This means that Miraheze Premium is not a separate corporate entity, nor is the sole proprietorship of anyone affiliated with Miraheze or anyone else.
 * The purpose of Miraheze Premium is to finance the continuing operation of Miraheze community wikis.
 * The existing monetary channels for donations are used to "pay" for Miraheze Premium.
 * There is no separate finance. The "pay" for Miraheze Premium is just a regular recurring donation to Miraheze Limited.
 * Under no circumstances should this service be confused for a separate organization.
 * Since there is no external proprietorship, this removes any possible financial incentive for running the premium service in a way that is not conductive to Miraheze's community-centric goals.

Technical basis

 * Miraheze Premium wikis have load-bearing tasks unlocked and the full developer options, with no (or almost no) grayed-out options in the wiki management sections. They can have files over the regular size limits, larger images, and have other limitations removed.
 * Extra extensions which would be cost-prohibitive to have working in all Miraheze wikis by default, will be enabled on Miraheze Premium.
 * Miraheze Premium wikis will be able to access a bot service and additional related support.
 * Miraheze Premium wikis will have an automatic exception in the Dormancy Policy because they help fund the project. This kind of exceptions have been manually handed before, with the same reasoning.
 * Miraheze Premium wikis are hosted in the same clusters as regular Miraheze wikis. This incentivizes that regular Miraheze users get benefitted from the arrangement, even if they can't reach the monthly average donation score.
 * The existence of Miraheze Premium would thus make the whole infrastructure more robust and stable.
 * Technical advances in purview of Premium services and goals will be able to benefit the whole community.
 * Non load-bearing tasks and improvements that come forth from Premium development and implementation will be available and of use to regular local wiki admins.
 * A Miraheze Premium volunteer team will be established within the wiki, so that regular systems engineers and global admins aren't overburdened by Premium tasks. This also allows Premium wikis to have a dedicated team for the troubleshooting of specific Premium problems and services.
 * Such team works wholly within the purview of the Miraheze Community, including the Board of Directors, and the Stewards.

Advantages

 * In-house development means existing Miraheze infrastructure to be used, reducing the workload.
 * Contrast: In the parallel proposal, using a wholly different infrastructure means more servers need to be maintained.
 * Pooling the servers means that existing Miraheze wikis will be more stable, by sharing increased server capacity to house the premium wikis.
 * Contrast: In the parallel proposal, additional external infrastructure and services will not benefit existing Miraheze in any way.
 * Administrative tasks are simplified.
 * Contrast: As per the other scheme, two wholly separate teams are needed, with one operating as a separate company. This company would not even have access to Miraheze's database, servers or infrastructure, which is tremendously inefficient and undermines the concept of " a premium Miraheze service".
 * Financial tasks are simplified, as the same Donation scheme is used, allowing Miraheze to fully audit its own finances and integrate immediately the Premium money as its own funding.
 * Contrast: As per the other proposal, the WikiForge was started with an intention to be a separate company, and thus will have its separate finances and have to audit costs internally. If costs of operation are allegedly not met, WikiForge will not give money to Miraheze at all, even while taking in Premium subscriptions (and thus otherwise potential donations) from Miraheze local admins.
 * There is no need to have "contracts", binding or otherwise, with anyone.
 * Contrast: In the other scenario there is the conflict of interest of a Nonprofit Organization signing a contract with its own Technical Director (which can vote for their own proposal) as a private party.

Disadvantages

 * There will be no monetary incentive to parallel private entities (if this can be said to be "disadvantageous", well, it may be for such party's private interest).

Support
(Voting is "not yet open before comments", probably. The "Support as proposer" came baked in with the form page.)--NimoStar (talk) 09:45, 14 April 2023 (UTC)
 * 1)  as proposer. NimoStar (talk) 09:45, 14 April 2023 (UTC)

Comments

 * I would like to clarify some points as it seems we might both be on the wrong page. The original proposal proposes that WikiForge be incorporated as a subsidiary company in order to make sure that any financial issue which afflicts WikiForge doesn't spread to Miraheze but as per the original proposal, WikiForge would still be a part of Miraheze Ltd, it wouldn't be its own completely separate organization.
 * Regarding the "technical basis", it is hard to provide what you're suggesting on our infrastructure. I'd like to point out that the only things grayed out in ManageWiki are options which we can't let users edit manually because it needs a system administrator to run a script or because setting an option too high will cause server instability. If we use our own infrastructure for this service, it would be impossible to offer things like SSO (we can't turn CentralAuth off on Miraheze wikis), LTS MediaWiki versions (impossible to support two versions on our infrastructure), and more. WikiForge will offer each server a dedicated server for itself which is why it'll run fast but we can't do that on our infrastructure, not by a long shot. If we let premium wikis on our own infrastructure access resource intensive extensions just because they pay for a service, it'll make everyone's loading times extremely high because our servers just can't accommodate that. If this service is hosted on our infrastructure then it'll be impossible to offer any extra feature.
 * This new service would need new servers to offer what has been proposed or else nothing proposed can be done. Our current infrastructure, however, cannot support more servers. We're hitting the resource limits on our servers and we cannot add new servers. In addition to that, we have a few broken disks so our capacity is crippled even more and one of them going down caused the current image outage. This new service would provide each wiki with its own server, not server sharing. If it shares servers, it won't be able to do things like using higher resource limits because that will slow down everyone's connection. As amended in the other proposal, the community will be able to audit the new service's finances in a page similar to Finance for this new service and, since it would be a subsidiary of Miraheze, it would be under our control and not under someone else's. Regarding your last point about the technical director being involved in this proposal, while that is true, he has said that he will refrain from voting on the proposal. Additionally, Universal Omega won't be on the Board for much longer, his term expires in a few months and he has said that he has no intention on running for re-election, since he is elected yearly by the technical community comprising of SRE members + other users who contribute to our code. Agent Isai  Talk to me! 11:52, 14 April 2023 (UTC)


 * Some additional points... Miraheze creating an in-house premium offering would be a much larger shift from its existing contract with the community vs welcoming an already-existing project as a subsidiary and separate service. Additionally, Miraheze would need new funds to stand up such a service, using existing donations for this effort would cause community riot without a doubt in my mind. I don't see that level of funding being reached and given in-house labor shortages, I don't see us having the resource-hours to establish it with only MH volunteers. --NotAracham (talk • contribs • global) 15:23, 14 April 2023 (UTC)
 * Why is this on a separate page? It can't be easily compared to the other proposal this way, which renders it a bit ineffective. Also, if the primary proposal is not fully understood (or even fully elucidated yet), it seems a bit difficult to propose an alternative based on that... just some initial thoughts. | -- FrozenPlum   15:34, 14 April 2023 (UTC)
 * This is even worse from the "commitment" and operational standpoint — the original is at least a separate service that is only acting as a subsidiary, this one is outright going back on the promise. As per other users that these suggestion are practically the same for the most parts, the suggesting user practically just outright rejects any further commitment to retain Miraheze's free service with a collaborating entity, while insisting that Miraheze is going back on its commitment, which makes it "you don't believe in a commitment but you insist on their previous commitment". Also, running it directly under Miraheze's name makes it completely dependent on Miraheze's own funds as opposed to a separate account which doesn't tap into Miraheze's budget as in the WikiForge proposal. This proposal will simply further affect Miraheze's commitment to free service while also leading to possible further stress on Miraheze's infrastructure. Will be opposing if this goes to vote. -- Luciferian Thomas  03:54, 15 April 2023 (UTC)