Minecraft Wiki
Advertisement

This is a rewritten version of the statement I originally posted as the answer to the survey on the future of the Gamepedia brand.

The statement itself is the first section of this page. Further sections add entirely new notes that supplement my stance on the future of Gamepedia.

Statement[]

Let's go back to the time before Fandom acquired Curse Media. Back then, the for Gamepedia's community, Gamepedia as a concept meant:

  • having more advanced technology than on Fandom;
  • having greater quality than on Fandom;
  • having less staff interference than on Fandom[note 1];
  • being more open to users than Fandom.

Yes, Gamepedia was smaller. It only covered games, but not many other subjects Fandom included. On Gamepedia, only staff could create wikis, while on Fandom, anyone could create a wiki in no time. So while Gamepedia didn't excel in size, it was like a more "elite" area than Fandom. In such an area, there were less editors and wikis, but that meant each editor or wiki could have more resources for themselves.

But there is no more certainty about the future of Gamepedia after it was acquired. Some things that have happened already may be viewed as troubling signs. Signs of that Gamepedia users will lose a noticeable part of GP's advanced tech, or that staff won't be as open and willing to listen as before.

Taking apart the identity of Gamepedia, however, would be a massive blow to the GP community. Having a separate identity for a small, more trusted group gives them some benefits. Not all of these benefits can be safely given to everyone outside that group. Yes, some of them can be granted to everyone, but some would have to be lost for everyone. So should Gamepedia as a concept be dissolved, any its advantages that rely on a separate identity will be gone forever.

I am, however, concerned not just with Gamepedia's branding and the tools editors have. In my list above, the one with Gamepedia traits, two of the four points center on a whole other part of Gamepedia: its staff. There are the "purple names" on the F/G server, who handle the most significant tasks. There are the "orange" Wiki Team members – wiki managers – who help wiki communities with day-to-day activities. (CTMs are "oranges" too, but I don't think they have much relevance to established communities.) I would go as far as to list GRASP here, even though they're certainly not staff.

Many members of these groups are strongly associated with the Gamepedia identity. They have shown they are willing to listen, not just take the path easiest for the corporation at the expense of users and editors. For that reason, I would prefer them to stay where they are, where they can somewhat help defend the well-being of the community.

However, I believe that for these same reasons, these people are unlikely to stay. Disintegrating the Gamepedia identity may make them redundant, and even if not, would be a great opportunity to lay them off. Chances are, should someone come to replace them, the replacements will be far less community-oriented.

I wish to ensure that the Gamepedia community sustains the least losses possible as a result of the changes coming with UCP and whatever happens later. I believe it's essential for GP's survival as a concept to maintain a strong separate identity. There was also an interesting related idea raised on the F/G server. This idea was to maintain two separate trust levels on the new platform. Otherwise, as I said above, whenever someone can't be raised to the higher level, everyone will have to be dropped to the lower one. Including those who have shown they don't deserve such distrust.

UCP's delivery to Gamepedia[]

As said above, when Fandom acquired Curse Media, the Gamepedia community lost any certainty of its future. The worst-case scenarios said the acquisition was an EEE move by Fandom, with GP wikis ending up forcibly moved to the Fandom platform. With the announcement of the Unified Community Platform, it became clear that this scenario was no longer probable, but some concerns about UCP remain.

Assuming there will be no two levels of trust as specified above, some features available now to Gamepedia users will no longer be available. These features may include:

  1. Wiki components:
    1. JavaScript without review. Currently, any sitewide JS edits apply immediately; this may result in that insecure or malicious scripts are executed. An attack on Fandom prompted them to introduce JavaScript review, when JS changes only go live when[note 2]/if[note 3] a staff member with special training[note 4] approves them.
    2. Widgets. Same as JS, they pose significant security problems.
    3. Global blocks. They will likely use Fandom's system of global blocks, which are done only by VSTF[note 5], not logged[note 6], have no public reasons stated[note 7], and, according to some statements, are de facto deemed unacceptable to discuss in public.[note 8]
  2. Customization:
    1. More-or-less complete local rights management. I'm not certain the ability to assign and demote bots will remain. Wikis without bureaucrats cannot possibly assign bots, and it's unclear how the policy towards community bureaucrats will change given the other changes in circumstances (probably also including a conversion of all wiki guardians to administrators).
    2. Complete MediaWiki: message customization. Due to security issues in Fandom's custom code and old MediaWiki, Fandom had to restrict which MediaWiki: system messages can be edited by local admins. There is no equivalent of this restriction on Gamepedia, and the original motivation behind it may no longer apply on UCP, the restriction may remain.
    3. More-or-less liberal customization policy. Fandom's policy is very restrictive and will most likely be reviewed before UCP Phase 1; otherwise, Gamepedia's policy may remain in effect until the implementation of the new design in Phase 2.
  3. Policy:
    1. More-or-less functional blocking policy. Fandom's view on admin blocks was that they should not be overturned except in ToS breaches, and blocked users were encouraged to find different communities. This had many undesirable effects, such as proliferation of duplicate wikis, and possibly also of questionable administration practices. This policy is going to be reviewed, but no details on this are publicly available as of now. There have been concerns that the new policy may enable bad actors among blocked users, blocking admins, or both. If the policy ends up flawed, and Gamepedia's current situation (arguably, not in need of improvement) gets replaced with that policy, wiki administration may be harmed.
  4. Development:
    1. Access to source code repositories. While this has not yet been used to implement actual code changes, it will be far more significant for UCP's repositories, which are currently private. While staff have stated they intend to open-source UCP in the future, there have been concerns this is actually not going to happen.
    2. Access to translation with minimal review. Gamepedia's current system is merge requests on GitLab repositories (which causes problems with the ability to insert invalid JSON on accident,[note 9] and others). UCP's current localization process only supports a very limited selection of languages (unsupported languages effectively can't be translated, and a restrictive customization policy may make non-centralized localization impossible). Furthermore, the current process is by far not supporting of collaboration between all involved translators. It's unclear to what extent this will improve.
    3. Access to issue repositories. Gamepedia's public GitLab repositories also serve for issue reports, where involved users may inform the platform team of issues with the platform itself. While it's unlikely to remain that way (when anyone with a GitLab account can make issues), having a completely private repository will severely harm both accountability and collaboration with staff on technical issues.

Footnotes[]

  1. While Gamepedia did require more of editors in some areas, it was mostly wiki managers more closely guiding smaller or newer wikis; Fandom didn't have WMs before the merger, and decisions by wiki admins would not be overridden in most cases. However, Fandom had a far more restrictive customization policy, more aggressive rollout of features (like auto-playing videos) without community input. In some cases, comments by Fandom staff even misled users about the nature of the platform's deficiencies. People who forked away from Fandom could end up globally blocked. As such, "interference" here refers to actions that are done by the company solely for their own interests with known harm to those of the communities.
  2. Don't expect your revisions to be approved on weekends or holidays.
  3. If there are perceived issues with the code (such as possible vulnerabilities), the code will be rejected.
  4. At the moment, to my knowledge, there is only one such staff member. It's uncertain what would happen if the "bus factor" led to the loss of even that person, but it's likely staff would rather lose all sitewide JS edits indefinitely than implement a less secure approval system.
  5. Fandom's equivalent to GRASP. GRASP and VSTF will merge into SOAP (Spam Obliteration and Prevention) for the purposes of the new platform.
  6. Some people say it's necessary to hide the identity of the actor behind the global block to prevent harassment. However, this is not effective as the reverts of disruptive edits are most likely logged with their actor, allowing readers to guess who may have performed the global block.
  7. The explanation for this is, basically, that some details of some global blocks may be private, therefore no details of any blocks should be disclosed.
  8. Note that this is radically different to WMF's handling of global blocks. Even if they involve private evidence and are expected to be done anonymously, they are performed by a special anonymous account (WMFOffice) with a generic reason like "harassment". It's probable that Fandom has ulterior motives in endorsing the system they have now; the motives being specifically and intentionally irreconcilable with accountability to the community.
  9. I did exactly that and crashed the staging environment once. The pipelines started including JSON validation after that.
Advertisement