UCP concerns

At this time, the Unified Community Platform (UCP) project is in full progress on Fandom. Gamepedia users, however, know too little about what awaits them after Gamepedia's migration to UCP, and they have voiced a number of concerns about Gamepedia's future in relation to the UCP project.

Origins

As for why these concerns even arise, it's important to know some details on the context of UCP and its rollout process.

Fandom's background

In late 2018, Gamepedia users did not hold Fandom in high regard. Fandom's outdated and very limited technology, the fixed-width Oasis skin, and heavily modified user experience made many Gamepedia users say they don't want to edit – and sometimes even read – on Fandom. Fandom's staff were thought of as focused on nothing but the company, often forcibly pushing their features such as videos without community input and using heavy-handed tactics to any interference with these features. (For the sake of fairness, Curse staff too did require some wikis to host, without changes, staff-approved videos on the subject.) These two issues led to some Fandom communities forking away to other platforms (sometimes with users being also blocked on all of Fandom in association to these forks). One of those platforms wikis ran to was Gamepedia.

For these same reasons, the Gamepedia Slack announcement of acquisition by Fandom was viewed extremely poorly. People compared the announcement to an April Fools' joke many months late. They criticized the copy-pasted staff responses that all looked like from a script written in advance by lawyers. They were afraid the acquisition was just an "embrace, extend, extinguish" move by Fandom to eliminate their largest competitor. Some communities were even considering jumping ship from Gamepedia and go somewhere else. Some actually did.

However, some people were actually willing to give Fandom a chance. And as it turned out later, the initial worst-case predictions would not hold. Some Gamepedia staff were brought into leadership positions in the new structure and many of the previous Product and Community staff members are no longer at Fandom. No mergers between same-subject communities between Fandom and Gamepedia were forced – Project Crossover ended up being voluntary, requiring consent from both sides. Fandom has taken some steps away from some of their past mistakes. And most importantly, they have announced that a new and modern platform – a much-wanted improvement to Fandom's old tech – would come to Fandom... and Gamepedia.

Yet even with all those things showing the acquisition won't be a total catastrophe for Gamepedia, its community members are still quite skeptical about what awaits them in the future. Right now, the UCP project is a most major source of such concerns. Another is an almost total absence of any assertive statements of the form "this thing bad for the community will not happen".

Differences in trust

One of the largest differences between Fandom and Gamepedia was who could create a wiki, or become an admin. On Fandom, anyone could create a wiki at any moment and be given bureaucrat and administrator permissions. On Gamepedia, all wiki creations would have to be approved by staff, and administrators ("wiki guardians") were also appointed only by staff – with the exception of a small number of established communities, often those coming from outside Gamepedia, that had the more typical system of bureaucrats and administrators.

Additionally, Gamepedia communities were more closely watched by wiki managers than Fandom communities were by staff. Gamepedia wiki managers were there to help, teach, and otherwise be available – including to overturn inappropriate use of administration tools, something Fandom staff would only do if such use violated their Terms of Service.

As a result of the above, Gamepedia admins could have a level of trust Fandom admins could not possibly have. Most notably, the ability to globally block any user across all of Gamepedia is well beyond what regular admins on Fandom (meaning, anyone willing to create a wiki) could have in their toolbox. The AbuseFilter extension was default on all Gamepedia wikis, while on Fandom it had to be requested – inappropriate use of the extension by admins could itself be abuse, and Fandom admins were not as thoroughly approved or monitored as their Gamepedia counterparts. Other moderation and customization tools were also available on Gamepedia that Fandom could not have due to excessive potential for abuse.

However, a unified platform would mean either a system of two levels of trust (which by itself could be the most beneficial solution to many communities, but would involve massive technical and social challenges), or an environment where any of Gamepedia's extra features that can't be granted to every admin will have to be granted to no admins. As a result, Gamepedia power users are concerned that their workflow will be in part disrupted by loss of some functionality.

Specific concerns

If you think something should be listed here, you can be bold and add it, however, please explain why it would be a concern, preferably with evidence to avoid sounding like it's pure speculation. You can add your own notes on listed issues. If in doubt about something, such as whether a concern is valid, please use the talk page to ask questions.

Please keep all concerns written as more-or-less neutral reports.

Non-English communities and custom system messages

UCP will involve custom code written specifically for Fandom. Some of that code will implement user-facing features that use custom text messages visible to users. Fandom and Gamepedia both have many non-English communities, but the messages will be written in English first and translated to other languages later.

On Gamepedia, there was no staff effort to localize system messages. All translation had to be performed by users, who had to use the rather inconvenient method of editing localization JSONs directly and submitting merge requests on GitLab. This has led to issues such as an error in the translated JSON crashing Gamepedia's staging environment if that language was chosen. For these reasons, as well as probably some others, it was considered to switch to some other translation setup,, however, this ended up outmoded by UCP.

At the moment, UCP actually includes translations for some officially supported languages, apparently pre-written by staff-approved parties. Should, however, users take issue with one of the translations, they need to write an issue report to staff using a very complex procedure. Additionally, support is provided only for a small number of languages (which, admittedly, take the majority of Fandom and Gamepedia's non-English communities)

The concerns raised from the Gamepedia side involved that there will be far less input from community members regarding translations, that there will be no global translations for languages staff do not support, that support for a language may be dropped, and that there will be no public repositories where code (including localization files) would be shown. According to the staff response, a proposal has been made, but not yet discussed, to address the issues, and a solution is supposed to be implemented before UCP is fully released. Without this proposal, languages outside the Top 10 may remain without translation overwrites. (As for the code repositories, staff have announced their intent to make them public.)

It is unlikely Crowdin will become accessible to editors. Not only inviting them will be a very difficult procedure, there is no way to separate NDA strings from non-NDA strings in the Crowdin setup. This has prompted concerns that errors may become no longer fixable easily if at all.

As an additional concern, some messages are added to the page using a less usual mechanism, cannot be linked to system messages and/or override the user's language preference by forcing the wiki language.

Review of Sitewide JavaScript may be difficult to get used to

For security purposes, Fandom requires all user-written sitewide JavaScript to pass review. Users may submit versions of JS pages to be approved by specially appointed staff. JavaScript only works for every visitor after approval. There aren't many staff approvers, likely just two of them. (Registered users may enable Test Mode per-wiki to test out new before they are approved.) JS reviews do not take place on holidays or weekends, so review may take up to several days. Even more, it's not unheard of to have valid code rejected, and there were claims of exploits having passed review.

At the moment, Gamepedia lets all admins edit JS directly. Requiring JS review for Gamepedia editors may disrupt the workflow of some wikis.

Public issue repositories may be gone

At the moment, Gamepedia's issue trackers are visible to everyone. All users with GitLab accounts may also create issue reports. (This excludes private repositories and private issues on public repositories.) Fandom has a staff-only issue tracker, and users can see nothing of what happens there. Users also can't always tell whether an issue is logged there, they can only file a ticket to staff. This may result in that some issues are reported many times over, and/or that some issues are not reported at all. The tracker being opaque also makes users trust staff less.

If the new platform would lack public repositories, it would harm Gamepedia power users. It would be like the old days of Gamepedia having only a private repository. Back then, users couldn't always tell whether an issue is at all logged. (Staff did sometimes give out ticket IDs to users to enable follow-ups.)

Design changes to Gamepedia wikis

Many Gamepedia editors would say that Fandom's Oasis skin is the key reason why they do not wish to edit on Fandom. Oasis is a fixed-width skin, and Fandom has a strict customization policy that disallows most design changes. This puts off Gamepedia editors, who can use the full-width Hydra skin and may make extensive changes with far less rigid bounds.

Before 2018, there were 2 skins on Fandom available - Monobook (the standard MediaWiki skin that got replaced by Vector in MediaWiki itself) and Oasis (a custom Wikia skin). In mid-2018, Fandom completely removed Monobook from the platform, and all users were left with just Oasis. This prompted some large Fandom wikis to fork away from Fandom.

The acquisition of Curse Media made Gamepedia editors fear that their wikis will be forcibly switched to Oasis. Staff promised, however, that Gamepedia will retain its Hydra skin until the new design is introduced with UCP Phase 2. This made people concerned that the new design will be too similar to Oasis. Staff revealed, though, that their plans are to have a highly customizable, "no one size fits all" design system, and not to impose strict limits on users if they can avoid that. Yet, naturally, Gamepedia power users weren't totally relieved, though for now they can only wait and see what the new system ends up being.

Admin-focused community building

Unlike Gamepedia, Fandom tended to elevate admins above regular users. Fandom staff would not overturn blocks by community admins if the block did not breach the Terms of Use. Staff would also deny adoption to users blocked anywhere as long as the block was within the ToU and not to prevent adoption. People often gave flawed reasons why it should be like that, saying that bad blocks and admins are subjective. Staff encouraged blocked users to create duplicate wikis.

After the acquisition, Fandom banned the creation of duplicate wikis, and introduced new blocking policies. However, staff are yet to introduce the new adoption policies that reflect this new approach. These policies could apply to Gamepedia as well. Some people have already said they worry these policies may cause harm if not executed well. In this bad case, they may let excessive blocks slip, bad-faith users retaliate against admins, or even both.

UCP may come to Gamepedia without enough preparation

Gamepedia and Fandom are different enough that migrating Gamepedia wikis to UCP may cause new and/or unexpected problems. As such, it's essential to catch as many errors as possible before all GP wikis are migrated. Staff are yet to say how they plan to migrate Gamepedia, though they did say the process would be like that for Fandom. If the migration happens too fast, editors won't have enough time to get used to the new tools, maintainers to fix their templates and such, and developers to solve the problems found on Gamepedia/UCP.

Loss of staff / WMs as a result of the migration

Many Gamepedia editors have a lot of respect for GP wiki managers and staff members. These people are often very experienced and rarely treat the community impersonally. Yet some of them may end up redundant and laid off as a result of the UCP migration. Such an event would harm community—staff trust, and the Gamepedia community may end up less well-coordinated.

Gamepedia's eventual fate

At the moment new wikis are not created on Gamepedia due to the UCP project. Any wiki created on the old Gamepedia platform would have to be migrated, which needs extra resources and is more likely to cause issues.

Staff are yet to say explicitly whether users could request or create wikis on Gamepedia after the migration to UCP. As some editors suspect Curse Media was acquired in part to eliminate Gamepedia, they worry that the eventual plan is to completely shut Gamepedia down as a brand. However, at least one editor called such an approach short-sighted and harmful to the company in the long term.

It is possible though that users have no information on this topic for the same reason as with the new adoption and blocking policies. It's indeed not an easy task to figure out how to separate gaming wikis between Gamepedia and Fandom domains. Yet even that hardly lets Gamepedia community members feel fully relieved.