6 parks indexed ●Explore. Rate. Compare. ●The Atlas of Minecraft Themeparks ●NEW: MineDisney - Disneyland Paris just listed ●145 community reviews ●Explore. Rate. Compare. ●6 parks indexed ●Explore. Rate. Compare. ●The Atlas of Minecraft Themeparks ●NEW: MineDisney - Disneyland Paris just listed ●145 community reviews ●Explore. Rate. Compare. ●
Internal Draft · Not for publication · Last Updated July 26, 2026
SCORING REFORM
REPRESENTATIVE PANEL
Right now, one editor scores every park alone. This proposal has every park pick a representative, and those representatives can score all the other parks - so no single person decides a park's fate. This page is just a draft of how that could work.
00Why This, Why Nowmotivation
Our homepage already carries an honest admission: the founder was personally connected to ExpeditionCraft, a park scored under the old system. Under that system, one editor decides every score alone. Nobody thinks that particular score was faked - the problem isn't bad faith, it's the setup. One person shouldn't be the one scoring a park they're personally tied to, and readers have no way to check that from outside. Removing that one score fixes one case. It doesn't fix the system that produced it.
The real fix isn't a stricter rule for one founder to recuse themselves - it's removing the single point of failure completely. If a park's score comes from many independent representatives instead of one person, no single person's bias can move that number alone. And every score comes with a name and a reason attached, out in the open for anyone to see.
01Current Model (For Reference)as documented in /public/methodology.php
One editorial visit produces five scores (Build Quality 25%, Ride Experience 25%, Theme Consistency 20%, Innovation 15%, Multiplayer Experience 15%), combined into parkovia_score. Community ratings can nudge the published number within a small, sample-gated band, but never touch the editorial figure itself. This proposal replaces how the editorial figure is produced - the community-modifier layer on top is untouched.
02Proposed Modelrepresentative panel
One representative per park. Every approved park picks one representative, who gets an account in the scoring system. It's an ongoing role tied to the park, not a one-time visit.
No scoring yourself, no scoring friends. A representative can never score their own park. They also can't score a park they've declared as a partner or friend - each rep keeps a simple declared list of those connections. Having a personal connection to another park is completely fine; reps and parks can be friends, partners, whatever they like. The rule only kicks in at the moment of scoring - a connected rep just sits that one out. (This only catches relationships people actually declare - more on that risk below.)
Everyone can score everyone else (except the excluded ones). Any representative can score any park in the pool, other than their own or a declared partner/friend park. If someone wants to review every other park - all 50, if the pool ever gets that big - they're free to. There's no cap and no forced rotation.
When a score actually goes live. A park's score isn't published until at least 5 different parks have reviewed it. Right now there are only 5 parks total, so that floor basically means "everyone takes part" - that's just an honest starting point, not the real target. As more parks join, the ongoing goal is that at least 75% of active representatives have reviewed a park before its score goes live. Once the 5-review floor is met, there's a 24-hour wait before the score actually publishes, giving a little more time for extra reviews to land. After that, representatives can still change their own score, or add one later if they hadn't yet - a park's number keeps improving over time instead of freezing at whatever the first reviews produced. Until any bar is met, a park keeps showing its last published score, or "Not yet scored" if it has none.
A few extreme scores can't swing the number. Instead of a plain average, each category's published score drops the highest and lowest submissions first, then averages what's left (a trimmed mean). That way, one biased, retaliatory, or just careless score can't move the number by much, whatever the reason behind it.
Expertise counts a bit more - but only when it agrees with everyone else. Each representative picks one category they're most experienced in. Their score there counts 1.3x instead of 1x - but only if it's reasonably close to what everyone else scored (within about 2 points). If it's far off, it counts the same as anyone else's. Being a specialist boosts your voice when you agree with the room, not when you're the outlier.
Every score comes with a reason, and it's public. Whenever a representative gives a score, they have to explain it in writing, and that explanation is published right next to the number - the same way editorial scores already show a public note today, just extended to every representative instead of one editor.
Governance constraint - not optional
The founder's tie to ExpeditionCraft is exactly the problem this reform is meant to fix. So it would defeat the purpose to give the founder - or any single staff member - a new kind of authority over the panel's results. Nobody like that gets to override a score, make a discretionary call on a dispute, or break a tie.
The founder's only ongoing role is watching participation - checking that representatives are actually showing up and taking part - never judging what they score or why. Anything that needs resolving, like a suspicious pattern or a registry dispute, goes through fixed automated rules or a rotating group of uninvolved representatives. Never one person's personal judgment call - including the founder's.
03Criteria Reshuffle5 criteria · proposed weights
Build Quality splits into two separate scores: Build (general park construction - paths, terrain, everything that isn't a ride) and Design (how well the coasters and attractions themselves are modeled - trackwork, ride vehicles, structural detail). A park can nail one without the other, so they deserve separate scores. Theme Consistency goes away as its own line, without moving anywhere else in particular - Build and Design will naturally reflect some of what it used to cover. Multiplayer Experience becomes Playing Experience, focused specifically on how well the server runs and how fun it actually is to play on. Innovation stays the same. Weights below are a starting proposal, not final - open to discussion before implementation.
20%
Build
General park construction: paths, terrain, non-ride structures, block-palette execution and scale across the park.
20%
Design
Modeling of the coasters and attractions themselves - trackwork, ride-vehicle shaping, structural detailing of each individual attraction.
25%
Ride Experience
Attraction variety, mechanical quality, pacing between zones, queueing design and throughput.
15%
Innovation
Technical creativity, originality of concept, command block engineering, plugin-enhanced features.
20%
Playing Experience
How well the server runs and how fun it actually is to play on - performance, stability, and overall feel while you're there.
20 + 20 + 25 + 15 + 20 = 100%. Ride Experience keeps the highest single weight, matching where it stands today. Playing Experience moves up from 15% to 20%, helping fill the space freed up by retiring Theme Consistency as its own line.
04How This Fits the Existing Score Stack
The panel's score - after trimming outliers and applying the specialization weight - becomes the new editorial figure, replacing what's today just called the Parkovia Score. It feeds into a park's public score exactly like the old editorial number did. The existing community layer on top (the ±1.0 clamp that ramps up with review count) doesn't change at all. In-person visits don't have to disappear - they could stay on as a check before a park joins the representative pool. But per the governance rule above, that check has to be run by someone other than the founder, and it can never override the panel's number.
05Open Risks & Questionsneeds resolution before build
Some collusion risk remains. Trimming outliers and blocking declared partners helps, but two reps who've never declared a relationship could still agree to score each other well. The backstop: flag scoring patterns that look too reciprocal or too clustered, and send them to a rotating group of uninvolved reps for review - never a single person's call.
The friend/partner list only catches what's declared. If two reps are quietly friendly but never say so, the registry won't stop them - and that's probably more common than an openly declared partnership. The registry handles the obvious case; the pattern-detection above has to catch the quiet one.
Not every specialty gets picked equally.Problem: if almost nobody picks "Innovation" as their specialty, that category's weighting bonus barely gets used, and the panel skews toward whatever specialties are common instead. Solution: there simply won't be experts in some categories, like Innovation — and that's fine, not something that needs fixing. A category with no declared specialist just gets scored at the standard 1x weight from everyone. Nothing breaks; it just means that category never gets the specialization bonus, exactly as it should when nobody has claimed expertise there.
Small-pool edge cases.Problem: the 5-review floor and the 75% target mostly agree while the pool is small, but once it grows past a handful of parks the two numbers can disagree, and it's unclear which one should decide. Solution: it's at least 5 parks. Once that's met, wait 24 hours, then publish the score — that gives a little more time for extra reviews to land first. After it's published, representatives can always change their own score, or add one later if they hadn't yet; either one updates the number. So a park's score isn't frozen at whatever the first 5 reviews produced — it keeps improving as more representatives take part, on the way toward the 75% target.
Privacy and consent.Problem: representative accounts hold personal data — a name, which park they're tied to, and justification text shown publicly under their name — which needs a real legal basis, not just an assumption that collecting it is fine. Solution: on registration, there's a field the representative has to accept before their account is created — capturing the exact text shown and a timestamp, the same explicit-consent-with-a-snapshot pattern already used for submissions and reviews, not a vaguer "legitimate interest" basis.
06Overviewthe flow, at a glance
Parkovia Archive
Submit a Park
Your privacy matters. We store only what's needed to list your park. A contact email is optional; if you provide one, it's stored as a one-way cryptographic hash and an encrypted value used only for editorial follow-up. No data is sold or shared. See our Privacy Policy. You may request deletion here or email mail@parkovia.com.
Cookies & data security.
We use only essential, functional cookies - things like keeping forms secure against forgery - never third-party trackers, ad networks, or analytics that follow you elsewhere.
IP addresses are stored only as one-way cryptographic hashes for abuse prevention, and are never sold or shared.
Read the full policy →