Requests for Comment/Premium offerings

Recently, our good friend Universal Omega started a new wiki hosting service called WikiForge, which offers some great features for premium wiki hosting. WikiForge shares many similarities with Miraheze, like focusing on its community, wanting to be a non-profit, and using extensions such as CreateWiki and ManageWiki. After talking with Universal Omega about this, we thought it would be a good idea to join forces and create a unified service that will help ensure our users satisfaction and the continued success of Miraheze. We wanted to bring this proposal to the Miraheze community for feedback, review, and discussion.

If approved, this would provide a great opportunity for Miraheze to gain some additional revenue to expand our services to accommodate growing demand and to combat slow loading speeds and infrastructure shortcomings. As always, Miraheze will remain free and will never paywall anything nor show you ads, this will just be an extra option available to those who choose it. We invite you to read the entire RfC and the FAQ for further information.

This is a preliminary advisory vote on whether the community supports the general idea. The Board, who will ultimately choose whether or not to implement the idea and how to, cannot consider it without this vote first. Any subsequent proposed legal agreements will be posted for community review after such a Board vote.

Introduction
Given the unique operation model for a premium service proposed by Universal Omega and the working example they have established under the brand name of WikiForge, the following partnership is proposed for community review:

WikiForge will become a subsidiary of Miraheze and will offer premium wiki hosting services. WikiForge branding will be reserved exclusively for Premium and would not be used for any other Miraheze service.

Miraheze would see no changes to its structure. No community roles (for example, Stewards and Global Sysops) will be drafted into this new service; they will continue to focus on Miraheze as will system administrators who will remain separate from any new teams.

Description of Service
WikiForge will be catered to those seeking a premium hosting experience and who currently cannot be served by Miraheze due to their project requirements (for example, a perennial request to SRE is the ability to use a third-party SSO provider to log users in. This cannot be done as it would be incompatible with CentralAuth), such as companies.

As a premium service funded with a reasonable monthly fee paid by its customers, WikiForge would offer its users additional benefits such as faster page loading speeds through dedicated server hosting, support for different versions of MediaWiki, a higher limit on expensive parser functions and much more. Such features have been requested by users in the past and provide an untapped opportunity to provide not-for-profit hosting for those who would otherwise find another provider for such services.

No initial funding will be provided by Miraheze for this project, WikiForge is intended to operate as a self-funding entity with the potential to donate excess funds after operating costs to the Miraheze project. WikiForge's finance and balance sheets will be available on a page similar to Finance so that the community may inspect and audit it as they wish.

Operation of Service
WikiForge will operate as a subsidiary of Miraheze that would be under the oversight of the Miraheze Board of Directors to whom it will report to. Day-to-day operations would be overseen by an oversight council composed of 4 community members elected by the Miraheze community and 4 members appointed by the Board of Directors for a total of 8 people on this council.

A director of Premium Operations position will be established, and the individual in this role will have technical and operational control under the WikiForge branding, in partnership with the oversight council. The Director of Premium Operations will report to the Miraheze Board and will coordinate work alongside Engineering Managers for Miraheze SRE when necessary for operational stability.

WikiForge's technical team will be separate from Miraheze -- their (future) system administrators would not be entitled to access to Miraheze infrastructure and vice versa, though they would still be under Miraheze NDA.

A contract will be signed between Miraheze and Universal Omega (as the originator of the WikiForge project) stating that if Miraheze ever shuts down or if the Miraheze community chooses to dissolve this partnership, WikiForge will revert to the control of Universal Omega.

WikiForge branding will be kept for Premium only, and it will not be funded by Miraheze user donations. Instead, WikiForge will only be funded by its paying customers. Any leftover revenue generated from WikiForge (after operational expenses are accounted for) will go to Miraheze and help ensure that Miraheze remains solvent along with ensuring continued growth and expansion of our infrastructure. However, WikiForge's budget will be separate from Miraheze's budget and will never tap into Miraheze's budget.

WikiForge's infrastructure will be separate from Miraheze's. No impact will be borne on Miraheze infrastructure nor will any changes occur. WikiForge will utilize cloud services to ensure the best experience for its users and to ensure Miraheze infrastructure is not overloaded by the need for new, dedicated servers.

While some policies such as the Terms of Use (and thus, the current Trust and Safety team and setup) and Privacy Policy will likely also apply to WikiForge (some, like the Terms of Use, in a slightly modified manner to remove Miraheze-specific mentions such as Dormancy Policy mentions), most Miraheze community policies will not. This is because some do not make sense in applying to a premium service.

Some examples:
 * Closing a paying wiki after 60 days of no edits under the Dormancy Policy, in this case non-payment policy would take precedence.
 * Wiki governance policies would not apply on premium wikis such as corporate intranet wikis, as those are not ruled by consensus but rather by a separate hierarchy.

In cases where there is incompatibility with Miraheze policy or new policy is needed, the oversight council will be charged with development and approval of policies/reconciliation of conflicts.

Benefit to the Community
By launching WikiForge, Miraheze will be able to offer additional services to users who require more features than what the standard free service provides. Furthermore, WikiForge's revenue (after operational costs) will support Miraheze's ongoing operations, providing another source of funds to ensure the sustainability of the organization.

Miraheze will benefit from the increased revenue generated by WikiForge, and our users will benefit from the additional features and services offered by the premium service if they choose. Additionally, it is our intent that WikiForge can act as an incubator for new features that will migrate back where possible to Miraheze users at no additional cost.

Miraheze proper will still be the main focus of everyone, new and existing features will NEVER be paywalled. WikiForge's goal is to provide additional services to those who require more features than possible on Miraheze (for example, providing the ability to run memory-intensive operations that would otherwise be declined on Miraheze due to technical limitations, or the ability to use a third-party SSO provider).

Miraheze will still be continued to be run by volunteers and this new endeavor would be purposefully separate from Miraheze proper in order to ensure that community and volunteer resources are not disproportionately allocated to WikiForge. By operating separately, WikiForge's staff will be able to focus on it and ensure success while Miraheze proper looks over its current community and ensures that it continues to thrive.

Miraheze's overall vision is unchanged, we will never stop being a not-for-profit and bow down to shareholders. Our users are the #1 focus and I believe that this proposal offers a unique opportunity to for Miraheze to provide a better experience for users. I look forward to hearing your thoughts and feedback on this proposal.

Proposed by: Agent Isai  Talk to me! 07:24, 13 April 2023 (UTC)

Co-proposed by: Universal Omega (talk) 07:27, 13 April 2023 (UTC)

Why is there a community vote on this proposal?
Part of Miraheze project's commitment to the community is that major decisions about the project will be community-driven. This is your opportunity to ask questions and help guide the project -- we encourage you to participate!

Based on the comments on this Request for Comments, the Board will then decide whether to enter this partnership or not and will consider additional considerations like legal and such.

How will this benefit Miraheze?
Surplus revenue from WikiForge (after operational costs) will be reinvested into Miraheze and will go into upgrading and expanding our services. This mean that Miraheze will be able to scale up better to accommodate demand without fearing hitting budgetary constraints and limitations.

Why does Miraheze need a premium option?
A subset of both our current community of wikis and those interested in joining Miraheze have complications today that drive them towards competitors or self-hosting.

Rather than excluding these individuals, we see a partnership as an opportunity to meet some of needs that a volunteer-driven, donation-funded project cannot:
 * High-availability cloud-based infrastructure
 * Extra services like SSO/opportunity to scale resources to meet needs without impacting unpaid services
 * Opportunity for professional assistance on setup/management of wikis
 * Meeting ISO compliance requirements for corporate clients w/ specialized needs, e.g. intranet wikis that may contain sensitive data.

Will this affect Miraheze's 100% free commitment?
No. Miraheze will continue to provide 100% free service to everyone. The only extra features that'll be made available on the new service are ones we can't provide on Miraheze due to technical restraints (like conflicts with our login system, technical limits, etc).

What are some examples of 'premium' features?
The only features that will be 'premium' are those incompatible with Miraheze's current setup. All other features will always remain free and Miraheze will never make them premium-only. Some potential examples of premium features include:


 * External SSO login (not possible on Miraheze due to CentralAuth)
 * Dedicated cloud server hosting with advanced performance options (all wikis share the same servers so not possible on Miraheze proper)
 * Lockdown extension (not possible on Miraheze due to conflicts with CentralAuth)
 * Installation of custom/high-compute extensions (with review) (not usually available on Miraheze as one wiki using too many resources will slow down all wikis)

Will Miraheze ever remove features only to make them 'premium'?
No, never. We promise to keep all current features and never make them premium-only. As long as a feature is not impossible due to technical limitations or security concerns, future feature requests will not be denied only to be made premium-only.

The technical teams for both Miraheze and WikiForge will be entirely separate so there is no financial incentive for our technical team to do that. Our teams will operate separately from WikiForge so we'll continue to put our users first, not profit.

Will this service be funded by Miraheze user donations?
No, WikiForge's budget will be completely separate and initial funding will not come from Miraheze.

Donations to the Miraheze project will never go towards WikiForge operations.

How will WikiForge be committed to community accountability and transparency?
WikiForge's day-to-day operations will be overseen by a committee/council composed of 4 members elected from the Miraheze community and 4 appointed by the Board of Directors. This means that the community will have direct representatives on the council to ensure that it compiles with their wishes. These council members will be up for re-election every year so they won't be indefinitely appointed and thus later shielded from scrutiny.

WikiForge's finances will also be transparent and will be listed on a page similar to Finance so that the community may audit and review it.

Will this new service use Miraheze infrastructure?
No. WikiForge will use its own cloud-based infrastructure.

Will Miraheze volunteers neglect Miraheze proper to focus on this new project?
No. WikiForge is a project separate from Miraheze proper which will be overseen by its own team. Our current volunteers will not be drafted nor ordered to contribute to this new project and their focus will always be on Miraheze.

Will Mirahze be liable for WikiForge's debts? How will Miraheze be covered in the case of a budget shortfall from WikiForge?
No. WikiForge will likely be incorporated as a subsidiary of Miraheze in order to ensure that debts from WikiForge do not affect Miraheze. Should there be a budget shortfall, Miraheze will be covered and will not be responsible for their debts.

Why does control revert to Universal Omega if Miraheze ceases operation or terminates its parternship? Why is there a contract at all?
The WikiForge project already exists today as an independent organization, created by Universal Omega. This proposal forms a partnership between Miraheze and WikiForge, bringing it under the banner of Miraheze Limited.

Not only does the contract recognize Universal Omega's role as founder of the service, it also gives assurance of continuity of services to paying customers should WikiForge's partnership with Miraheze be terminated.

What happens if the community doesn't like the partnership later?
This proposal is a partnership, first and foremost. If community approval should shift to disapproval at a later date, a similar proposal can be raised to dissolve the partnership and WikiForge ownership would revert to Universal Omega if successful.

Where will information about WikiForge be displayed on Miraheze, if anywhere?
This is yet to be decided, but the likely location will be on some Meta pages. We do not intend to add any 'upsell' language to local wiki management pages nor add any advertisements to wikis.

Proposal 1 (Premium offering)
WikiForge is established as Miraheze's premium branch per the above proposal.

Comments

 * I'd like to remind everyone that you are not permitted to vote until this RfC is officially opened. This RfC is currently a draft, so it's not open yet. Tali64³ (talk) 12:09, 13 April 2023 (UTC)

Comments from Sheep42

 *  I personally don't see this as having any potential of going in a good direction. Sure, it does say only features that aren't available on mh by this point will be premium, but the "line" is hard to draw. For one, it says some extensions would be premium features. I can't really see how this would work, but I can't really envision something that would be good. Sheep42 (talk) 19:42, 13 April 2023 (UTC)
 * Only things technically improbable on Miraheze due to its infrastructure setup and resource limitations would be premium (SSO, Dedicated Hosting, ElasticSearch (even though Miraheze aims to have that one eventually also), etc......), since it is a different infrastructure it opens up more realm of possibility, and another funding avenue for Miraheze also. Say this proposal fails when it goes live, then the same features would still not be present on Miraheze, would on WikiForge, but it wouldn't be a part of Miraheze. If anything this will help bring more features to feee Miraheze with more technical developers and assistance on the technical level building things for WikiForge, and integrating with Miraheze proper when possible and feasable. I do reiterate once again features will NOT be paywalled. Not only would that negatively impacr Miraheze as a whole, but would also go against the core principles of Miraheze and why the volunteers signed on in the first place. It go against everything Miraheze stands for, and not only would the board not let that happen, volunteers including technical volunteers would likely seriously oppose such a thing. It just will not happen. Universal Omega (talk) 19:59, 13 April 2023 (UTC)

Comments from Imontegav

 *  I think there is a risk that, in the long term, the implementation of premium benefits could give way to the monetization of other features that were previously free. --Imontegav (talk) 10:27, 13 April 2023 (UTC)
 * There would be no incentive for Miraheze to paywall anything as both services would be run by their own teams. All this new service will do is offer extra options unavailable on Miraheze due to technical reasons (for example, custom SSO for companies who need it. That's not supported on Miraheze because it conflicts with our login system) and surplus revenue would fund Miraheze's current free infrastructure. Is there anything in particular that we could do to put that concern at ease? Agent Isai  Talk to me! 12:17, 13 April 2023 (UTC)
 * Sorry but that is just patently untrue, as Universal Omega is, according to the very summary above, the owner of the paid service. At the same time, he is part of the Miraheze Board of Directors. Yes, you can say "each is run by their own team", but teams with overlapping the same people at the highest level, one of which pays the other, and thus there is a clear "incentive".--NimoStar (talk) 13:23, 13 April 2023 (UTC)
 * To clarify a few things, UO is but one member of the board of directors and can easily be overruled by the others if proposals are not in MH's interest, there are others that would keep them in check. They've also previously stated their intention to not seek re-election to their term once it completes in August, something that would likely be hastened in the case of this partnership.  This is also part of the intent of having an oversight council, to avoid hasty/hostile/rogue actions not in the interest of one or both services. Do you have any additional suggestions towards what might help with some of these concerns? --NotAracham (talk • contribs • global) 15:50, 13 April 2023 (UTC)

Comments from SpazJR61

 *  To be honest, I don't like things being locked behind paywall. Sure, things getting expensive and servers needs money to operate but I'm a bit concerned about features that were previously free gonna become paid and one day maybe Miraheze needs to rely on ads.-- SpazJR61 12:00, 13 April 2023 (UTC)
 * Rest assured, nothing will be paywalled. As stated in my response above, there would be no incentive to paywall things as both teams running Miraheze and WikiForge would be separate and ultimately, the goal of this new service is to help fund the free infrastructure in order to ensure continued future solvency. See also the FAQ for more info. Is there anything we can do to put these concerns at ease? Agent Isai  Talk to me! 12:17, 13 April 2023 (UTC)
 * The day Miraheze needs to chop features deliberately or rely on ads is the day Miraheze will have been condemned as financially and conceptually unsustainable and no longer be Miraheze anymore. This will not lead to that. If anything it is an attempt to stave it off and make it less likely to happen. Cash flow is a cold hard truth and while I have concerns about the execution of this idea, any effort that maintains the spirit of the core service is one worth considering because relying on gratis exclusively as a larger platform has been a barely-kept miracle as it is. There is a fallacy at play: the slippery slope, except this is an additive project that would hold itself up and give back its extras to Miraheze, and otherwise be its own wiki farm. Its presence does not affect the ethos and operation of Miraheze itself. If anything it could benefit outside of finance: discoveries through premium development could be shared with Miraheze if they fit in, helping this platform grow while that platform does its own thing because it is affluent enough to afford things that could only come from premium sponsorship. --Raidarr (talk) 12:46, 13 April 2023 (UTC)
 * Whatever man. I'm just saying and I still have my doubts though (and it's less likely of course). SpazJR61 14:16, 13 April 2023 (UTC)
 * Except that there is no "slippery slope" at all, just the reality of the proposal. The very text says that there nothing will be paywalled just because we can. Which means by default, there can or will be paywall if there are alleged good reasons for it; and rest assured, there will be - and are already displayed pre-emptively on this very page. The wording about having high availability and reliability, and adapted to high demand, already relies on Miraheze being low availability by default, low reliability, and unable to cope with high demand. In other words, this is only needed in scenario Miraheze is going under hard and fast, which is fittingly already covered in the "terms" that full control always reverts to Universal Omega when Miraheze "ceases operations" (!). What a bold statement to make if any, and clear onto intentions. Why could this service not be provided within the Miraheze foundation, and requires a "partnership" with a board member and former SRE? So we "need" Miraheze to outsource paid functions, to someone that already works in Miraheze, and that was suppossed to do this job for Miraheze; but rest assured, there is no compromise or ethical concerns! None in the slightest! Seems legit.--NimoStar (talk) 14:25, 13 April 2023 (UTC)
 * The proposal makes it clear that as long as there's no technical or security impediment, all requested features will still be added to Miraheze. All WikiForge would add is the ability to use features you otherwise can't on Miraheze proper due to technical constraints. The technical teams on both services will be separate so there will be no incentive for anyone to decline adding a feature where there's no technical thing that restricts us from doing so. The wording "just because we can" is meant to convey the idea that technical requests or features won't be arbitrarily declined on the basis of "we can implement this but we want you to pay". I don't think you'll disagree with me that Miraheze is, despite our best efforts, sometimes low in terms of availability or reliability. The db141 incident in November-December where 1,000+ wikis were unavailable for ~20+ days was an example of this and the current files outage is another. This new service would be high availability as it'll be hosted on the cloud and not on its own self-hosted hardware which can sometimes experience some troubles, as ours does sometimes. The agreement is only an if, not when. No one intends for Miraheze to go under any time soon and everyone wants to see it survive for many more years. Hopefully, 20+, 30+, even more, as a good free service, which there aren't many of unfortunately. Agent Isai  Talk to me! 18:48, 13 April 2023 (UTC)

Comments from Átkýv L.

 * I might not be the one who'd use this service anytime soon, but I'm definitely excited to see Miraheze grow as a community. I believe that the promises listed are sufficiently realistic and trust that the executives would try their best to keep them. Good luck guys! --Átkýv L. (talk) 09:42, 13 April 2023 (UTC) Moved and striked out as this is a draft

Comments from NimoStar

 *  This is institutionally dangerous, see Premium offerings (in-house proposal) for my alternative developed within Miraheze itself. (This isn't a "vote" yet, this is a position. Stop censoring the overwhelmingly negative response, over 4 negative positions have had their "votes" "censored", yet the single positive one was awarded a green orb, ho; I have restored red orbs to rejection "pre-votes" for balance.) >> The implementation of premium always carries the risk that the site will be further monetized. It doesn't matter if there is such a "commitment" that "this will not be the case". I'm pretty sure that "100% free" is already a "commitment" to "no premium options". This also seems a fandom-like way to monetize being SRE or other such position at miraheze, by offering third-party services. Universal Omega is a member of Board of Directors, this is a clear conflict of interest, running Miraheze in one hand, organizing into contracting his own service with Miraheze money on the other, nothing else to say. Full reject and I call on everyone to do the same with one firm resolve. --NimoStar (talk) 12:57, 13 April 2023 (UTC)
 * What makes you believe that the Board would go back on a commitment it made to the community? Is there any evidence of this having happened before? I believe that if this happened there would be huge community backlash. In addition if I understand correctly it is made clear that "Miraheze money" will not be used for this new service. It appears that the whole premise of this oppose is that Miraheze management is bad-faith and untrustworthy and does not care about what it commits to. --DeeM28 (talk) 13:07, 13 April 2023 (UTC)
 * It doesn't matter if its good or bad faith. This very "offer" is already the "cold hard truth" of "going back". Tell me, if certain free features are excluded and only appear in premium, is that "100% free"? Both intuition and logic demonstrate easily this is not so. It could be, say, some % free. But what %? 95%? 80%? 1%? The moment the paywalls start, then it is game over. It creates a de facto systemic incentive structure in which the holders of the for-pay structure prefer that there is no free alternative to their "services", or that such actively doesn't work, so that people have to pay. This incentive structure is inherent to the system and exists irrespective of noble words and/or alleged moral desires, whether true or false intentions it does not matter, only structure matters. ...Curiously you do not comment on the obvious conflict that Board members stand to gain directly from essentially using their position to Miraheze to contract themselves (via the user base). This is extremely sketchy no matter what. If Universal Omega can use his "skills" to create all this service, why didn't he do it within Miraheze, seeing as he is part of the highest ruling body? He resigns as SRE and surprise, a whole new infrastructure, which is outside Miraheze under his private control, yet for which Miraheze users are supposed somehow to pay for. Not only that, but, "ultimate control" will reside within this "wikiforge" (!). Furthermore that this is what some higher ups are up to as we have an unprecedented file system/server outage is unimaginably bleak. Outages and featureless for the many, premium SREngineering, perks and stability for the few? Miraheze was an oasis from rampant monetization, it seems the desert storm is coming to bury it. --NimoStar (talk) 13:17, 13 April 2023 (UTC)
 * Further-furthermore, if the premium service is intended to be fully funded by users paying, then why is the service not within miraheze itself and fully responsive to user demands and community oversight? After all, it's Miraheze userbase who will be paying for operation, this is written as such. Not only that, the text is very sneaky in many points, such that wikiforge intends to operate as nonprofit. So far we know, it's a wholly owned single person enterprise, not organized as a formal nonprofit at all (and not even formally existing?). I would say this is Miraheze Gold™, but actually, that would be good in comparison, since at least that would come under direct Miraheze control, and this will fall outside. The text even sneakily puts provisions if Miraheze ceases operations, subtly but decisively opening the door that Miraheze would be scrapped and only premium Wikiforge remains as the "savior". For obvious reasons this is entirely unacceptable, and I have a strong hunch from this presentation that without Miraheze userbase as "potential customers" and Miraheze servers infrastructure for the "free" part of its "freemium" model (built on the shoulders and sweat of unpaid volunteers, and free wiki communities), Wikiforge doesn't have a single user and will not even exist. In other words, it just needs the free userbase, free labor and free resources for a private endeavor. For proving me wrong, fully incorporate Wikiforge into Miraheze proper (since local admins will pay for it anyways) and make it a community-run subdivision subject entirely to the institutional process.--NimoStar (talk) 14:03, 13 April 2023 (UTC)
 * I want to add that WikiForge supposedly won't rely on Miraheze for the financial and technical operation - it will have it's own technical infrastructure and won't rely on Miraheze for money (supposedly of course, per the RfC). However, other than that, I agree with parts of what you're saying, namely that I think it's pretty bad that UO is doing this as one of the directors of MH, and have serious concerns about one of the biggest supposed benefits that this RfC argues, that the money surplus generated by WikiForge would go towards Miraheze, after paying for "operational costs". OrangeStar (talk) 14:24, 13 April 2023 (UTC)
 * It (supposedly) woudn't rely on Miraheze as an institutional organization, but it would wholly rely, as per this initiative, in Miraheze users essentially abandoning the Miraheze community hosting for its private hosting "option". This relationship is essentially parasitic and structurally closer to predation than to cooperation: Wikiforge benefits from weakening Miraheze, while the benefits for community hosting are apparently nil, save some unspecified "money" (who or how to audit "costs of operation" of a one-person enterprise), which is even phrased as "This may mean", "WikiForge is intended to operate", "wanting to be a non-profit" etc.etc.; in legalese, "none of this is a binding agreement and terms are subject to be changed at any time". --NimoStar (talk) 14:40, 13 April 2023 (UTC)
 * Yeah I have zero confidence in this, feels more like just UO looking to use the Miraheze brand and it's users for his own farm, which is a pretty funny thing to do when you're the director of Miraheze. OrangeStar (talk) 15:47, 13 April 2023 (UTC)
 * He won't be for much longer, he doesn't intend to re-run for technical director. Agent Isai  Talk to me! 18:36, 13 April 2023 (UTC)
 * Yet he will certainly want then to be "director of premium operations", am I not correct? And when Miraheze goes under, the WikiForge built by the whole of volunteer workforce will revert to being under private ownership, is this not correct? --NimoStar (talk) 08:52, 14 April 2023 (UTC)
 * Well this is a great time to raise these concerns. The vote here is whether or not to propose to the Board consideration of the topic, not the final agreement. The final legal agreement will be passed before the community again for review. I see you want definitive wording, no "may", "might", etc. Regarding the intent to run as a non-profit, I meant that WikiForge intended to run as one if it were an independent organization. Now that it's coming under the Miraheze fold, it won't "intend" to be, it will be. Would you like for the organization's budget and costs to be listed on a page, akin to Finance on Miraheze so that users may audit that? That's intended but can be added into the proposal. Agent Isai  Talk to me! 18:36, 13 April 2023 (UTC)
 * Anything that can help assuage concerns raised so far (within reason) might be good to help clarify the proposal. This is a difficult one to wrap one's head around without it. | -- FrozenPlum   02:49, 14 April 2023 (UTC)
 * Why does Wikiforge need to be a separate branding under private ownership "contracted" by Miraheze, when Miraheze itself can host its own premium service, which can be governed and audited by the same institution without the need for a different and separate infrastructure/permission/servers? Yes, "wikiforge was already made by Universal Omega", but this doesn't anwer why Miraheze can't have it's own premium service, since Miraheze is also already made. --NimoStar (talk) 09:11, 14 April 2023 (UTC)

Comments from DeeM28

 * My first question regarding this matter would be in the case that this agreement does not happen is WikiForge a premium-only service or in the absence of an agreement with Miraheze would it also overlap and seek to provide non-premium services? My second question is whether there are any realistic prospects of development achievements that also benefit Miraheze without WikiForge? Another way to phrase it would be: without WikiForge does Miraheze think there is any chance that there will be enough interested volunteers to develop new features? The third question is whether Miraheze is - in order to appease some potential opposing votes - willing to categorically commit to a list of features that would be available on WikiForge only and commit that any other features will be available to Miraheze as well? --DeeM28 (talk) 13:05, 13 April 2023 (UTC)
 * I've also chatted a bit with UO/CA on the matter and can give some additional context here (though they or anyone else who's discussed it are free to correct any misstatements on my part): In the absence of an agreement, WikiForge intends to pursue lower-cost/free non-premium tiers once sufficiently established. Regarding development achievements, I can't predict the future, but MH has always had challenges with attracting talent that a paid project may not.  Based on some interest I've seen from reputable non-MH-affiliated talent from other corners of the web, I think this is quite possible.  Regarding specific feature lists, what MH can offer depends on MH's architecture and what its SRE teams can support.  There's ZERO ability under the current proposal for WikiForge to say that MH core can't have a feature because it's premium-only, only a matter of SRE/infrastructure limitations at MH. I don't see the current MH board or community accepting anything less than that. --NotAracham (talk • contribs • global) 15:39, 13 April 2023 (UTC)
 * I personally don't want to see paid tiers or anything like that get anywhere near Miraheze. Including by affiliation. Other websites can exist, Miraheze can't stop them from simply existing, but not going along with Miraheze Naleksuh (talk) 15:42, 13 April 2023 (UTC)
 * , In the absence of an agreement WikiForge might provide free services as well, but it wasn't fully decided yet. One thing that I am developing technically for WikiForge is a new RequestWiki that is easier to use, and allows to configure more settings, as well as select premium tier, etc... that is something that I will at least attempt on the main RequestWiki form (well setting configuration, etc...) (though more difficult due to RequestWiki already being highly active on Miraheze). Features that will be available on WikiForge as premium-only, will include (eventually, not all is live for possibility yet, but is being worked on) SSO, without CentralAuth, the ability to opt out of most global features Miraheze uses, Global AbuseFilter's, showing up on WikiDiscover, etc... if they so wish, CirrusSearch/ElasticSearch (though Miraheze will implement this when they also have the technical resources to do so from my understanding), MediaWiki multiversion, so if say one wiki wants an extension not yet compatible with the latest version of MediaWiki, other supported versions will be possible to stay on if they wish, it also makes it easier to upgrade overall, giving the wikis full autonomy. As well as dedicated hosting, which means wikis can pay for a dedicated VM to host their wiki for faster speeds, etc... and the cost of this would be the exact cost of hosting this based on their resource needs + an undecided small fee that 100% of it goes back into WikiForge operations costs, and anything left, goes to fund Miraheze. A content policy might be established for subdomain wikis, but less-so for custom domains. This is so that it maintains SEO and reputation for subdomain wikis. Additionally, we likely would not let any reception wikis on, premium or otherwise, custom domain or otherwise, as they have always been a pretty big issue everywhere else they went. It wouldn't be anarchy without rules. Just less global forced control. Universal Omega (talk) 17:46, 13 April 2023 (UTC)
 * Personally, I'd rather see cooperation and mutual benefit than competition, which is my impression of the proposal. It's interesting and enlightening to see the logic behind those that would rather things to the other way. | -- FrozenPlum   15:43, 15 April 2023 (UTC)

Notes by proposer

 * For the record, as concerns were raised of my affiliation with the board, I would like to note, that as a Miraheze board member, not only do I not have the only say and could easily be outvoted, all Miraheze financial usage is posted publicly on Finance, if the community felt from that Miraheze funds went into WikiForge (which they won't, only the reverse), seperate vote could always be opened by the community to abolish this. The board might not be technically bound to the community when it comes to the legal structure of Miraheze, but has always listened to the will of the community, and would definitely not go back on any commitments made to the community. If it did, it would have serious backlash, and that would be then end of a community centric wikifarm, if it was no longer listening to the community. Also would like to note, this RfC is preliminary, if the community supports the idea of it. The board would then draft up how it should go about implementation and bring any final agreements to the community for another vote and ratification of the plan. The board will not make autocratic decisions that go against the will of the community. Universal Omega (talk) 17:46, 13 April 2023 (UTC)

Comments from Ondo

 * moving a question I asked on Discord here, as it didn't get an answer there. If WikiForge is staffed by volunteers, how do we know they will have enough capacity to manage the project? As far as I understand, lack of funding is not the only problem Miraheze has, it's also the fact that volunteer staff has less time than full-time employees. If WikiForge is a premium service, it will be a competitor of for-profit companies, so why should someone choose WikiForge over a company that does have paid staff and, therefore, has quicker reaction time when things go wrong and can provide better and faster customer support? After all, both WikiForge and Miraheze would pick volunteers from the same pool of people (engineers with MediaWiki skills willing to work as volunteers). I think this is important because if WikiForge is not successful, Miraheze will be spending efforts on a partnership that might not yield benefits. Overall I like the idea, I'm just unsure about the execution or if it's feasible at all.--Ondo (talk) 18:23, 13 April 2023 (UTC)

Comments from FrozenPlum

 * Can see possible benefits: I'd support if refined as a complementary service, making ultra-clear no paywalling (MH continues as MH has--my current understanding). A common use case our wiki falls into:
 * Folks looking for advanced, absent features, a need that's been there a while.
 * I've seen game wikis starting on MH, later go independent needing advanced/data features/stability, having extension/skin problems, or extension/skin removed to later have the maker fix it, request re-adding etc.
 * We considered a move to MH but our skin wasn't updated in time (no ticket put to the maker). We submitted a ticket, WMF folks opted to maintain, but it took time. Because of MH "latest version of MW" policy, we'd have been left looking "rebranded", for months, which is not ideal for a game wiki to inside a game by game maker. We stayed independent.
 * We considered MH because I do the server stuff, but am not well. I wanted to give our users a feasible future option to continue, if I can't.
 * Next, DPL3 went unsupported (CA/UO fixed that, massive thanks). Then Cargo issues/disabled, and SMW is in experimental status only. Again we're kept independent. A paid option preventing this, is valuable. It caters to a different set of wiki clients; to those that value continuity and stability, over the latest version of MW (fo me, continuity/stability is always greater value than the "latest and the greatest"--that has a purpose, but it may not be many MH user's priority--my understanding is, it's a differentiating factor from other farms?).
 * Some want a MW LTS version for reliable extension use. Furthermore, the ability to know/determine, or especially have more warning, when extensions are disabled/changed; to not have to scramble if one is removed/dropped. Time to file tickets to extension/skin makers for the opportunity to fix/patch. I get why dropping stuff quickly is a necessity on MH, and for wikis with stock extensions, non-complex or hobby wikis, that's probably not an issue, hence why different tiers makes sense. Those that value/need continuity/stability the above is a must MH can't offer.
 * I've helped game wikis in MH discord to see them forced independent for the above, including official game wikis. If WF offers what these (different priority) wikis need, then they could stay under the MH umbrella. That, to me, is a win. Especially if there's mutual benefit.
 * This still brought my donations/time to MH (back then, MH was a positive place to help out, apart from the recent community volunteer issues).
 * When positive, IMO it draws nerds (it drew me and another).
 * I can envision folks working premium, occasionally donating time to the free side.
 * It's a greatly underserved area. Any wiki growing enough to be endorsed/used by outside players (like a game community, publication, company) may find themselves there. I'd encourage folks to imagine that scenario and ask what their options would be?
 * Concern re:Donations, I believe Agent said 80% come from fundraisers. I have monthly/recurring donations to MH despite being independent, I donate as it's a worthwhile cause.| -- FrozenPlum   19:17, 13 April 2023 (UTC)

Comments from SchizoidNightmares

 * This is a pragmatic, albeit controversial, proposal. This semi-commercial option could allow for additional revenue for Miraheze. It may catch some of the people leaving for other "competitors." Miraheze's operating costs have ballooned since the pandemic. I wonder if donations will always be able to cover all the costs in the future. Frankly, I'm surprised Miraheze has lasted as long as it has. --SchizoidNightmares (talk) 01:50, 14 April 2023 (UTC)
 * People "leaving" or "not choosing" Miraheze should not even concern Miraheze. For example, the most important "complaint" was that Miraheze is not conductive to corporate for-profit intranet wikis. But this was never the purpose. Corporate for-profit intranet wikis woudn't donate money to Miraheze anyways. People leaving Miraheze because they want commercial services is a net win for Miraheze hosting, since it reduces costs and doesn't lose out on any benefits. It's essentially people saying "I don't want your free food". That's ok: More for us. The least "clients" Miraheze has, and the more community-fociused they are, the better it works. --NimoStar (talk) 09:14, 14 April 2023 (UTC)
 * Less users is generally not a good thing for affordability and the long-term viability of a community, unless those users happen to be very dedicated and generous — which is almost never the case. The more users a community has, generally the greater number of potential donors there are. Cost of server hosting is generally less per user the greater the scale. It is not like Miraheze has a fixed quantity of pie and therefore the less people there are, the more pie there is to go around. That pie only comes from revenue. Something Miraheze could certainly gain more of if this proposal is put into practice. --SchizoidNightmares (talk) 14:53, 14 April 2023 (UTC)
 * People leaving to run their own servers with similar needs is a concern, as often these are people who volunteered their time at MH to help out. Also, you're pidgeonholing and your argument to unlikely wikisto be on MH anyways as corporate has the financial means to run their own wikis. I think many are referring to wikis that are not small, not large, the porridge is just right. I should know, as I've helped a number of "middle-ground" wikis that began on MH but left for the lack of service proposed. I'd generally try to remain neutral, put yourself in other's shoes, and think about needs that aren't always able to be pigeonholed to the scenarios you're currently representing. | -- FrozenPlum   15:43, 15 April 2023 (UTC)

Comments from LuciferianThomas

 * I can see the benefits in this partnership, providing services that Miraheze would otherwise be incapable of providing as a non-profit service that relies solely on donations; but I do also understand concerns raised by certain users here. A few questions that I would like to ask the following questions:
 * The proposal entails that excess revenue will be directed to Miraheze after paying off "operational costs". While Miraheze's finances are open to the public such that payments from WikiForge can be visible, can WikiForge also commit to the same level of transparency regarding their finances for community inspection?
 * I understand that the limited resources will lead to the unavailability of certain features in Miraheze. If this partnership has a deal, can Miraheze make a dedicated page for documenting which and why certain features (mainly extensions) are unavailable on Miraheze but available in the premium level?
 * Is there currently a proposed model for the finances of WikiForge, as in pricing, expected revenue, expected costs and expected amount that will be directed back to Miraheze?
 * For worst and best case scenarios:
 * If WikiForge proves to be a failed concept, what will be done to wikis that migrated from Miraheze? If so, how can it be done so that it does not negatively impact Miraheze's normal operations at all?
 * If WikiForge proves to be a successful concept and is able to drive sufficient revenue to Miraheze such that Miraheze is able to catch up with the technical capabilities, what else is there for WikiForge to be "premium" from Miraheze? Is it remotely possible that donations from WikiForge be manually limited, say lower pricing and lower net revenue, to restrict Miraheze's development and expansion to maintain the advantages of the paid tier?
 * Could Miraheze's donators be driven away from their current donations and turning to WikiForge seeking for better services? Are there any estimations on the impact on Miraheze's finances due to this?
 * Can Miraheze devote to ensure currently unavailable features (e.g. CirrusSearch) be introduced once Miraheze has the capability to?
 * Thank you. -- Luciferian Thomas  05:19, 14 April 2023 (UTC)
 * Re: 1. Definitely. I'll add this to the proposal.
 * Re: 2. Of course, we'll make a page detailing why certain features are declined. Adding a page detailing why certain things are unavailable is actually a long-term project of mine as every so often people ask for extensions and features which we've declined due to a variety of reasons but yes, there would definitely be a commitment to documenting why a feature is only available on premium.
 * Re: 3. There is none, this will be decided later on as we take into account operating costs and industry standards.
 * Re: 4, part 1: They will be re-migrated to Miraheze as any normal wiki is migrated. If there's any features we can't provide, we'll tell the wiki operators but overall Miraheze and WikiForge won't diverge much in terms of core features so the wiki operators might not feel any real inconvenience.
 * Re: 4, part 2: There will be things that Miraheze will never be able to support because they conflict with our setup such as custom SSO, higher resource limits (such as high expensive parser function limits), the ability to use LTS MediaWiki versions, and such. We unfortunately cannot support the first one as it conflicts with CentralAuth. Two can't be supported because even on good servers, high expensive parser function limits might slow down everyone else's loading experience, especially depending on what they're doing while on WikiForge, every wiki will be on its own server. Three can't be done because that'd potentially cause breakages with things like CentralAuth/login/global rights, global AbuseFilters, global blocks, and much more as a lot changes from one LTS version to another so running wikis on the same network but on different MediaWiki versions will likely cause database schéma incompatibilities and will break a lot of things.
 * Re: 5. I don't think any donors will be driven away. As it stands, some months, we get not one donor or at most, one donation. Finance in the month of February is a testament of the fact that we don't receive a lot of donations. A good portion of our annual donation base is generated during the Fundraiser (I'd say anywhere from 50-80% of our yearly operating costs come from the Fundraiser alone).
 * Re: 6. It is a long-term goal to support CirrusSearch and in fact, two ElasticSearch servers already exist in our infrastructure. I won't speak on behalf of the technical team but from what I've heard them say, the only reason we don't have CirrusSearch on all wikis at the moment is because we use an ElasticSearch version that is too new for MediaWiki and we can't use an older one as our internal system log system (Graylog) requires a newer version. Once MediaWiki devs support new versions of ElasticSearch, it's the goal for Miraheze to implement it. Agent Isai  Talk to me! 05:42, 14 April 2023 (UTC)
 * Thank you Agent Isai for your detailed response. My current stance is a  leaning towards support for the concept, but I would want way more information on the predicted finance model of WikiForge when incorporated with Miraheze. Plausibility must first be confirmed before any votes our decisions. Here is a plan for Agent and Cosmic to consider:
 * Using trends of the past expansion of Miraheze, estimate the amount required to support an expansion in Miraheze's infrastructure to avoid overloading in the short term and long term, and at best, to also cover the costs required for the extensions that will initially be restricted to premium.
 * This amount will then obviously be the target minimum amount for WikiForge to subsidize Miraheze. Accounting for this amount, do market research on expected operational expenses, and calculate suggested pricings to cover the costs and subsidies.
 * If possible, estimate how long it'll take before WikiForge will start subsidizing the minimum amount. This can be in terms of times or services provided.
 * Feel free to leave in variables like the number of customers (wikis hosted) or the scale of resources needed, graphs are very welcomed. This would give the community a better understanding of the proposal and plans. -- Luciferian Thomas  05:34, 15 April 2023 (UTC)
 * LuciferianThomas, thanks for these questions, they hadn't occurred to me, and it was helpful to read the answers provided (thanks also to Agent). The page for documenting reasoning for non-implementation seems particularly useful in my mind (currently these are scattered all over phab and difficult to find otherwise). | -- FrozenPlum   15:43, 15 April 2023 (UTC)

Procedural note from DeeM28

 * Procedural note I find that everyone has misunderstood the idea of a draft Request for Comments and this process has turned into a de facto vote despite the vote denominations being "banned" until this RfC opens. It is my understanding that in a draft RfC users should make comments about wording, vague statements, unclear terminology, potential amendments and alternative ideas rather than comment on the substance of the proposals and make value judgments about whether the proposal is good or not. If that is not the case then what is the difference between a draft RfC and an open RfC - only the fact that votes icons are seemingly not allowed but users are able to nevertheless clearly express views about the proposal itself instead of about the form of the draft and alternative ideas? --DeeM28 (talk) 12:28, 14 April 2023 (UTC)


 * Seems someone scooped my intentional not-a-vote visual and applied it to everyone (not warranted, but I may know why). To explain what I wouldn't to Naleuksuh (being berated doesn't invite sharing such): Indicators to summarize reactions/impressions (like thumbs/arrows up/down) are appreciated by users, as they enable scannability for particular views to read/understand/reply to; that's also respectful of user's time (and a common-sense necessity nowadays)--we couldn't do that on Meta, we got only a generic wall of text (which takes 20x longer to sift though, is prohibitive, and not good UX). Color/shape is indicative of more than a single subject/intent (red=negative, no, caution, hot, halt, oppose, etc; green=positive, good, go, support--support/oppose are not actually common meanings in most/other contexts). I did a generic circle only for my own section, as a temporary fix, until I could make a template or raise the issue, it now seems forced.


 * A good indicator to pause and think more about a (design/use) problem, is when users use something other than how it was intended. Typically, it doesn't indicate they're being difficult, or they don't understand its use (both assumptions may be incorrect/incomplete), more often it indicates an unmet/misunderstood need (as outlined above). If a template is not intended for reuse, I'd suggest in future: 1) Pausing to ask why, and shedding assumption, 2) The docs for the template get updated to restrict use (not done), 3) Provide a comparable alternative (perhaps the most fruitful/direct--so I've made a temporary one, called Template:Notavote for a sense of clarity, and good cheer. Tbf, before making my initial "not-a-vote" circle, I tried a green CSS arrow up first, though that was a bit too "reddit-esque" and the wisdom of up/down voting is currently debated from a behavioural/connotation standpoint. | -- FrozenPlum   08:03, 15 April 2023 (UTC)
 * I have once again, applied this to only my own comment section above, will be interesting to see what (if anything) happens. I also think the unsolicited sectioning was an added indicator that other users were having similar readability/usability issues, though it creates its own issue from a continuing-indented/unindented-conversation perspective, perhaps). | -- FrozenPlum   08:09, 15 April 2023 (UTC)