User:Raidarr

Somewhere, deep in the Tropical Wikis, past the land of Orain, southwind of Miraheze and east of the dilapidated kingdom of Wikia, in the MAW of Fandom beneath the Sky from which wikimedians Shout, there is an Oasis...

So you want to make a wiki farm

An open letter of sorts that is probably easier to review in wikitext than long blobs on discord.

Starting off

Core members should individually review and consider the following points; enact as described, enact with changes, no action, something like that. Going through these one at a time, perhaps with internal polls can get the common ground here set quickly. Changes should be reviewed and understood by the founders collectively. For simplicity this means founding members of tech and stewards.

This is not inherently 'the best way' to do things, just thoughts for how to give it a shot based on the lessons of Miraheze, MakeAWiki and other attempts. Some of this I admit is experiments I've thought of for Miraheze but did not bother for one reason or another.

Teams

How to govern this thing. Here's my thoughts. Rather than focus so much on the rights, why don't we focus on groups that take over areas of responsibility. These areas off the top of my head are the Executive (name pending), Tech, Stewards, Trust and Safety and News.

Executive is the core group of volunteers who will make major decisions and help push the project forward. Details vary but this should include the legal owner, directors of major teams (TS, tech), the stewards, news and what have you. It can include founding members of tech but I'm not sure every tech person going into the future should automatically have membership. It should be possible to have 'at large' trusted others who don't necessarily fit in a clean box. So maybe just the owner/directors inherently have the position, but founders and select tech, stewards, specialists can be invited by executive vote. This would be a more chill version of a Board (see miraheze) and would exist to democratize major platform decisions, and for all groups to come together. The key is that this group will meet or regularly discuss/report on things every so often. Quarterly is probably the easiest idea, but it could be monthly. Reporting would be decisions taken, things to work on, that sort of thing. Communication is key. This seeks to avoid the shortcomings of how Miraheze is managed while not putting power in the hands of a 'ruler'.

Tech of course is what it says on the tin. Importantly, tech focuses on its own affairs - tech capacity should not mix with community capacity (unless someone is a tech + steward). They can address technical issues on the spot but should leave things like bans to other groups.

Stewards are both CVTand the group which represents the platform to member wikis. They also assess and implement community decisions. As the time and need arises, this could split into subteams - CVT, a community support group, wiki creation; but this is not necessary at this time. Also as time goes on this could be a position elected, but I do not want to emulate Miraheze on this necessarily. For now it would be prudent to have executive-appointed stewards and let the platform grow a bit, then ease into a more democratic model if that is still desired. A similar idea was attempted by WikiTide. Depending on progress a good time to revisit this would be right around the new year. An interesting angle is to elect stewards specifically and then let their supporting teams (cvt etc) be appointed. This would chop bureaucracy while still giving agency to the community.

Trust and Safety may not entirely be necessary, but for this case its purpose should be to respond to legal things, develop best practices for all groups, be able to audit or investigate staff conduct (stewards, tech etc), and explore ways to improve the safety and professionalism of WikiOasis.

The news team would be something new and exist to keep a record of happenings, maintain a news area (including publishing content from other teams such as the executive) and broadcast happenings that the community should know about. This is an example of something people with no rights could contribute to and build up their record if they're interested in advanced volunteering.

Other teams could be created that are less 'major' and are supervised by a trusted functionary probably from the executive group, such as meta documentation if there are volunteers for that, translation if that becomes a major factor, and more. These could be initiated by the executive group or the community itself.

But, for now, probably best to avoid adding too many kitchens so to speak.

The global community

Miraheze has two community problems that run deep. One is lack of insightful voting and decisions. This needs to change from the ground up, any decision should be made with good reasoning and a civic interest. The other is that meta doesn't represent the global community. It represents the tiny handful who trickle in. Most wikis just want to mind their own business, or the farm is irrelevant to them and the wiki is just free hosting for something that happens elsewhere.

So firstly WO needs to pick an attitude. It can either be like a Miraheze but more accepting of its small part in the world, and be as hands off as possible. This includes nixing infeasible policies like 'you must get steward approval for scope changes'. Or it can embrace being a smaller platform and encourage close contact with wiki operators, similar to Weird Gloop. Not everyone might engage but the door would be open to every operator, and democracy would be funneled into the true stakeholders of the platform, the wiki operators.

The former would be easier to manage but if it's chosen, there should be another avoidance of a miraheze flaw: wikis taking advantage of unlimited free hosting. It should come with certain resource limits I believe, and thought of a premium aspect should start early. It is not a pleasant life living off begging for donations every year, and donation-only I believe is only ideal if the farm is committed to small, sustainable projects. Which would mean twisting arms a bit more at wiki creation to ensure a requestor is serious if they're starting something new, and looking closely at existing communities if something that already exists is moving.

In any case to start with, major decisions should be mostly founder-initiated, however if we want to pursue something more open these decisions should be public facing for comment and improvement. If the decision is unpopular then even if the executive wants it, it should be reconsidered. No area imo should be totally off limits to open discussion unless necessary, including tech, though obviously tech should take point on things where only they would know what's going on anyway. But if it can be passed through the community, it should be for transparency and to possibly catch issues.

more?

We'll see what comes of this, I'd like to dig into hard Content Policy questions and stuff later but this is to set what the farm wants to be first, then it can answer those questions.

but...

• staff wiki?
• email/ticketing/custom domain contact. lean inexpensive, this is not a big business™

Pages

• Category tree: Documentation -- Support -- Policies -- Teams (pending on feedback on the Teams idea). Most things should fit in these main categories.
• Help Center? This should not be a duplication from Miraheze.
• Trust and Safety, this is kinda my shtick here so it could use a draft.
• Content Policy should probably have an uppercase p, to be worked on soonish.