Tupper has been posting asking for ideas for an official VRC wiki, figured to post this here for people not on Twitter
Addendums:
2 Likes
One other thing to note: the license of the wiki is being potentially reconsidered from the proposed one after discussion with another user:
2 Likes
Yeah, i saw those posts online. Being able to update it community wise is a good thing. I don’t really have much to say, not having a lot of experience making wikis myself.
Maybe more a question than a suggestion, but what would be the limitations of this wiki, for example on community projects. Having documentation on how to integrate with the major community tools or framework. It’s still technically VRC related, but not directly to the game.
Would this have it’s place on this wiki as it would be community driven, or is the main direction to have our own wiki/docs somewhere else ?
Edit: Tupper agrees https://x.com/dtupper/status/1785064208473694587
2 Likes
The community should be able to participate in a major way!
Dokuwiki has a feature called namespaces. This makes it relatively each for the community to have their own dedicated space on the wiki.
For example, the community could create community:cheese_guides:how_to_get_cheese without needing to create their own VRRat lore wiki.
4 Likes
Long time editor from the unofficial VRChat Legends Wiki here. I used to be very active in the past but the workload got too huge and I had to take a step back. Nowadays I mostly moderate and resolve disputes.
Any wiki that isn’t Fandom with an open license that clarifies that contributed writings are being “gifted to the community” should be decent. Fandom is a for-profit company that has a lot of flaws, is riddled with ads and enforces poor design choices. If I could go back and do things differently I would never have chosen Fandom. If I had the financials to migrate it and self host instead I would also have done so.
The MediaWiki CMS has a lot of established plugins which most wiki editors will already be familiar with. It is a lot more customizable to use rather than DokuWiki and will scale well with hundreds of active editors while DokuWiki will have many growth problems. Mediawiki is used by the largest and most iconic Wiki - Wikipedia. There are a huge selection of plugins and template themes for MediaWiki for adding additional features, for example custom permissions that allow only certain editors to edit certain pages, syncing content with other databases and more. No need to re-invent the wheel so to speak. A lot of features can be configured instead of re-developed inhouse.
I’m mostly writing this at the top of my head so apologies if its not the best formatted or structured.
Some key things that would be helpful:
- Have a license attached at the bottom on the default editing page. (Is in MediaWiki)
- Guidelines on wiki formatting and TOS on the bottom of the editing page. (Is in MediaWiki)
- Which level of enforced requirement to link sources? This is very difficult to judge. Content creators will likely edit direct information and not link any sources at all. Requiring too many sources will reduce the amount of contributors.
- The wiki should be publicly editable for registered accounts, otherwise contributors will be sparse.
- Only protect important pages and the top ones linked from the start page.
- Linking accounts (with VRChat) looks like an initially good idea but may be off-putting to improvised community creators documenting on how to implement resources they’ve created. For example there are many Blender and Unity creators who don’t actively use the game much aside from testing and debugging. It would be very useful for cross-moderation though.
- Requiring users to be ranked up will reduce the amount of editors substantially.
- MediaWiki could potentially be synced with groups/profiles on the VRChat website using extensions that can read databases. These probably already exist and only need to be configured, instead of developed from scratch.
- Protected articles need a link and explanation on where to apply and ask for permission to edit. (Is in MediaWiki)
What should the Wiki be - and what shouldn’t it be?
- The TOS for communities needs to clarify what is, and what is not acceptable to document. For example, documenting disputes and conflicts between different communities should probably not be allowed at all.
- Several communities are focused on conflict and will not be possible to document at all. When they realize this they will likely vandalize. Moderators need to be engaged in order to realize this.
- Will documenting night-clubs or content aimed at “content-gated” material be acceptable? This will create a conflict between many creators because they can’t talk about their creations and make the wiki completely uninteresting for them.
- Having a wiki that is only technically-aimed will be A LOT easier to maintain than one that documents living communities of people.
- How to handle deletion requests. A lot of users will want to delete content that other people have created because of personal conflicts. If the sole editor is the one requesting deletions that is generally a good enough cause for deletion, but if they donated their writings and it’s really useful information. Will you delete it anyway? This requires careful judgements to make the wiki “good” and “useful” while also respecting integrity.
- How to handle requests to not have your community, tool, person or characters be documented. Will they be granted even if they don’t violate any TOS?
Important topics to iron out regarding moderation of community wikis:
- Promote a decent team of community moderators from active editors who are familiar with wiki editing. It is A LOT more work to moderate and maintain than most realize at first glance and requires checking the recent edits history tab pretty much daily. Wikis “work” because they value editors who contribute for free and donate their time. They stop working when they become too difficult to use or editors are punished when they contribute what they see as useful information.
- For dispute resolution you will have to block many users from editing who also use the game. IP bans are required and need to be separated from those who use the game. The wiki will be very prone to vandalism and “shitposting” and create a lot of discourse if editors also get their VRChat game account banned if they do so. This will likely still be required depending on the severity.
- Adding a delay for newly created accounts before they are allowed to edit will reduce the amount of many conflicts. A delay of 24-48 hours for new accounts will let most “heads cool down” if they decide to engage in vandalism.
- A lot of vandalism will be from young editors so having an additional requirement to be 18+ may be beneficial. How this should be enforced is difficult but it could help reduce the amount of edits done in bad faith and overall moderation work load even if it’s just a simple text based confirmation.
The most common disputes on VRChat Legends are from inexperienced authors with (mostly) good intentions who end up not understanding what Wikis actually are. Many mistake them for microblogs like social media where you can type whatever you wish instead of public documents that anyone can edit that require good faith and integrity in order to do so. Especially when writing about other users or other their communities. More editors will want to exaggerate, sound overly flashy and “cool” instead of writing text that is useful and accurate.
It should be very clear when registering that:
- All edits should aim to be educational and informative.
- All text is public service for a common shared good.
- Your writings are donated and WILL be edited by other users.
- When you post on the wiki, you forfeit part of the copyright to your writings.
- Shitposting and hateful content is not allowed.
These are some things I could think of right now. Here are the VRChat Legends community guidelines that have developed over time here that may be helpful for reference. They’re unfortunately due for a rewrite and not written in any kind of formal or legal speech at all.
Hopefully this is helpful in some way for you to determine how to go ahead with this. Feel free to reach out to me on Discord. Same username “Cragsand” there.
Best Regards
Crag
4 Likes
Thank you for the post! This is excellent information, and I’m really glad someone who worked on that wiki is present in the conversation.
A lot of your advice hits home on my thoughts. Summarising a bit, I think that establishing a clear, narrow purpose to start makes the most sense and solves many problems, and we can expand with new namespaces if we see a need arise.
I want to focus initially on two main things:
- A “user manual” on how to use VRChat, including tips, best practices, guides
- Community-authored technical guides and docs on content creation
Despite users asking for “lore” and “history,” that’s not what our official wiki is for. Agreed on that front.
This is all excellent advice. I want to keep the SSO requirement for various reasons, including hopefully a future way to let users show off that they’re contributors. The 24-48 hour delay for first login sounds great.
I wanted to go with MediaWiki to start, but got a good amount of push-back internally with previous MW administrators citing pain with its tech stack and integration. That’s why we went with DokuWiki.
Do you think DokuWiki is enough of an issue that we should reconsider at this early point, rather than later on when we have to do a bunch of manual work to migrate?
2 Likes
Quick correction: Wikipedia utilizes Mediawiki, not Dokuwiki.
I definitely think there should be VRChat linking, I imagine the majority of the people utilizing the wiki will have a VRChat account, whether they actively use it or not. I think it’ll definitely help in terms of accountability imo.
1 Like
I do wanna throw my hat into the discussion here and repost some thoughts I talked about with other people:
I feel like definitely lore pages should be closely monitored, you don’t want anybody sitting there and just shoving their world or themselves in there for advertising’s sake and not for anything actually meaningful people will want to read.
What I think it should be for:
- Information about iconic worlds, such as the ones listed in the “Classic” row. Great Pug and such.
- Notable avatars
(Ugandan knuckles, brushes, popular avatar bases(?)) - Notable history
(Ugandan knuckles, important updates, large-scale events (next bullet point)) - Notable events
(Stuff that’s large-scale such as VKet, Furality, etc) - Terminology
- Stuff about RP in general
(not specific lore but just how to RP, general etiquette, avatar stuff, etc.)
What I’m not sure about:
- Event groups
(clubs and such) - RP groups
- Specific Communities
(Transacademy, Helping Hands, etc)
With all three here the biggest reason is that I worry people will just make pages to advertise their groups without a lot of substance and such and end up being clutter
Definitely Should Not Be Added:
- Pages on specific people
(could be concerns for privacy, misinformation, and god forbid if that person ever gets into some drama, although creators of specific worlds and avatars should probably have categories for their content though, just not full pages.) - Large-scale RP lore
(confusing at best, making shit up on the spot for worse, generally just clutter in my opinion, a lot of it can’t really be considered “history” because half the time it isn’t based on any RPs that actually happened and just someone making it up on the spot)
1 Like
For clarification I meant that MediaWiki is used by Wikipedia, not DocuWiki. Apologies that this was misunderstood. I typed the sentence weirdly. Edited. @TrixxedHeart
- DocuWiki does not require any database but relies on PHP and local text files to save data.
- MediaWiki uses MySQL/MariaDB.
I don’t have enough experience working with databases to say for sure when either is preferable to use but as far as I know if you write to files directly it may cause problems. For example if writes happen simultaneously in different asynchronous processes, like multiple read/writes from an Apache HTTP server, you may get an error in a text file but not using a dedicated database like MySQL/MariaDB. I also found a plugin for DocuWiki to use a local sqlite database but this seems very vulnerable to sudden lack of future updates.
This kind of design with files is fine for small and personal wikis but not recommended for speed or scale when a website has hundreds or thousands of simultaneous users. There may be tools to import those text files into mediawiki but since the formatting markup i.e. “wikicode” is different between the two any conversion would need to be translated so it will not be an easy seamless translate without manually reviewing it. Maybe with AI but that’s not something I’d rely on. So using DokuWiki even if it may be simpler you may be painting yourselves into a corner.
MediaWiki database structure:
https://www.mediawiki.org/wiki/Manual:Database_layout
DokuWiki database structure (or lack thereof):
https://www.dokuwiki.org/faq:database
Tl;dr. I recommend MediaWiki.
4 Likes
Honestly, all things considered, I’m leaning pretty heavily to not allowing “lore” content to start. I think the Legends wiki serves that purpose just fine.
Later on, there might be some interesting history or context to document, but to start I have a pretty narrow set of things to nail.
2 Likes
Good to hear, it should start focused and aim to serve its niche well rather to attempt to do many things at a lower standard.
Hope the NC licensing issue has been considered further. I think NC must be stripped, but absent any willingness to budge on that, please patch the deficiency in what, for the purposes of the license, you will define as commercial use - both acceptable and unacceptable uses, in spirit. I imagine you wouldn’t want someone to publish the wiki as a book in a non-transformative way and sell it, but you might not be interested in demonetizing a content creator producing a useful video tutorial series on YouTube based on the content of the wiki.
For that matter, it would also help to offer guidelines on what is considered a derivative work; practically speaking, those are the two major ambiguities. Useful code snippets (or Udon graph examples) embedded inside wiki articles being MIT licensed or Public Domain (or the required license that confers similar terms, as PD isn’t treated the same everywhere) would remove one of the most significant concerns, for example.
3 Likes
After a bit more discussion, we’ve concluded that the NC clause will stay, meaning we’ll be going with CC Attribution-Noncommercial-Share Alike 4.0 International. The reasoning for including includes us not wanting people to straight up reprint our work and monetize, along with other protections.
The issue then comes down to a “trust me, bro” problem, right? We know we wouldn’t go and request a takedown for someone quoting portions of our wiki, using knowledge from it, or screenshots of it in a monetized YouTube video, but you don’t know that, partially because “commercial use” is (intentionally) fuzzy.
We recognize these concerns and understand where you’re coming from. Where it makes sense and is compliant with understanding and meaningful licensing, we’ll make clarifications – but generally, the text of CC BY-NC-SA 4.0 will apply.
As a side note, we did not choose a “ND” license intentionally, as derivative creations are perfectly fine and help protect some of the content we’re talking about.
With that settled, our next steps are as follows:
- Add all of our official “Core” content (basically, updated stuff from the Readme)
- Some minor visual improvements and theming
- Create wiki guidelines and share for internal review
- Get feedback from, ask for contributions from some initial community contributors (anyone here want to start out?
) - Go live!
Our ETA for launch is the end of June, but this may change depending on team load.
1 Like
It comes down to there being no bright-line definition of “non-commercial”, and legally un-settled questions about what constitutes “derivative work”. “Trust me bro” is related but not exclusively the issue.
What I’m looking for, then, given that NC will stay, is
- An explicit MIT license for code snippets, and
- An acceptable use policy that provides clear examples of usages that won’t be pursued. If it comforts the lawyer, it can be non-exhaustive, but it should exist, and ideally be updated and clarified as necessary.
I want to underscore that while I can’t imagine that you/the company as it exists now would go after small creators, I think is far from inconceivable that your eventual successors might not be as averse to pursuing damages against parties who have made significant revenue in a related sector.
5 Likes
As an update, after a lot of internal discussion and risk-checking, we’ve moved the content of the wiki to CC BY-SA 4.0:
We’ve also considered alternatives to DokuWiki, like MediaWiki or a managed host (wiki.gg is a contender, for example). However, we want to keep things in-house if possible.
Thankfully, if that turns out to be a bad choice, migration isn’t too terrible. 
Our next steps are to contact some community members who have experience running wikis and wiki-like things and invite them to both the wiki and a discussion space on Discord so we can get their feedback and thoughts.
5 Likes
Good to see!!! That was one of my only major worries.
I think Dokuwiki will probably be fine, although Mediawiki might have some more support in terms of plugins which I’d consider looking into. Especially with the likes of TemplateStyles being useful for creating more robust and clean templates for users to use for specific things along with making templates more lightweight (as it makes it so only the CSS associated with that template is loaded when that template is actively used).
I’m not sure if Dokuwiki has an alternative or something like that is already built in, but should possibly be considered.
1 Like
Excellent! Thank you for the update, and thank you for listening!
1 Like
For transparency, the main issue with MediaWiki is that setting up and running our own instance is, to put it lightly, a huge pain in the butt.
We have a few team members that have had long-term expert-level involvement with running MW instances at scale, and I’m fairly certain I saw them having flashbacks when I mentioned considering MW. 
4 Likes
Hey y’all, here’s where we’re at.
We’ve been trying to dedicate time to putting more of our Readme content into the wiki as a starter, but we’ve been struggling to find time to do so. Both our Creators and Community team are maximally resourced (as in, we’re swamped) so while I understand why we’ve been laggy, I’m also sad because I’m personally very invested in getting this out to everyone.
As such, I have a proposal: I’d like to open up the wiki to key contributors first.
You would be a volunteer that we would work with to help build the foundations of the wiki and establish the core content. Ideally, I want you to grow into Wiki Mods, who are community members with the power to help us grow the information there in an organized, mindful way. You will have ownership over many parts of the wiki and will collaborate closely with the VRChat team on official segments of the wiki.
The wiki would open for viewing right away, but we wouldn’t promote or link to it until we have a decent amount of content.
As such, I’m putting out this form for those interested. Those who participate and remain active will receive recognition in the form of anything else we can think up to help you show off your hard work to others.
Thank you!
edit: Modified the items in the recognition.
6 Likes
Hmmmmm, maybe.
2 Likes
Question: This question is super open-ended. Is that intentional?
There’s a lot of caveats I think. Example: as a user, contributor, or maintainer? And are these websites/things that have a wiki, or the actual software they use?
Edit: I ended up assuming it was software
1 Like