RFC: On-site Revision Proposals & Set Plans

[wescopeland]

• Start Date: 2026-02-04
• References: Revision Titles - Getting site wide notifications for Revision votes #4507, https://docs.retroachievements.org/guidelines/content/achievement-set-revisions.html

Version History

Version	Date	Summary
1.0	2026-02-04	Initial RFC
1.1	2026-02-10	Incorporate community feedback
1.2	2026-02-18	Incorporate community feedback
1.3	2026-02-23	Incorporate community feedback

Summary

This RFC proposes moving the achievement set revision process from Discord to the website. Developers can draft revision plans on-site, get feedback through threaded discussions, and vote without ever touching Discord.

A plan may contain any combination of seven types of actions:

• Rescoring existing achievements
• Demoting achievements (making no longer unlockable)
• Promoting achievements (making unlockable)
• Retyping existing achievements (Progression / Win Condition / Missable)
• Transferring existing achievements to/from subsets (including proposing entirely new subsets)
• Proposing new achievement designs
• Adjusting an existing achievement's trigger logic

Plans move through defined states, have their own forum topics for discussion, and use a polling system for votes. Where possible, approved plans have their changes execute automatically.

Players who've mastered a game or played it recently get notified when someone proposes changes.

Voting is anonymous. Results stay hidden until the poll closes, then only the final approval percentage is shown.

Plans with subset transfers need sign-off from a review team before voting can start.

When a plan passes, the system auto-executes what it can (rescores, demotions, retypes, transfers). Plans that add new achievements or modify existing achievements need a developer to claim and implement them. Unclaimed approved plans that cannot be auto-executed go to an "approved plans pool" for any developer to claim.

Down the road, we could let players propose plans too. Player-proposed plans would need extra safeguards, such as lots of upvotes or a developer sponsor, before ever reaching a vote.

Table of Contents

• Version History
• Summary
• Motivation
  • The Problem
  • Why move it on-site?
• Glossary
• Detailed Design
  • Data Model
  • Enum Values
  • Configuration
  • Plan Type Rules
  • Process Flow
    • 1. Plan Creation
    • 2. Submission
    • 3. Discussion and Review Phase
    • 4. Starting the Vote
    • 5. Voting
    • 6. Poll Resolution
    • 7. Implementation (Non-Auto Plans)
  • Self-Revisions
  • QA Retypes
  • Discussion Spaces
  • Forum Integration
    • Plan Forum Topic
    • Game Official Forum Topic Post
  • Plan Reviews
  • One Plan Per Game
  • Notifications
    • Defining "Invested Players"
    • Game Page Indicator
    • Notification Events
  • Access Control
• Example Plan Definitions
• Future Considerations
  • Player Voting on Tiebreakers
  • Player-Proposed Plans

Motivation

The Problem

The current revision process has several pain points:

1. Tight Discord dependency. Revisions live on Discord, so site-only users can't participate. Context gets split between RA and Discord.
2. Lack of transparency. Discord threads are hard to search, reference, or audit. Players outside the conversation can't see why decisions were made. Developers sometimes don't know why their subset proposal got rejected.
3. Players get blindsided. Someone spends 40 hours on a game, then discovers the set was revised while they weren't looking. Frustration and backlash follow.
4. Too much friction. Getting a revision off the ground means contacting active developers, making forum posts, creating Discord threads, pinging teams, and starting polls. Each step has a reason behind it, but good ideas die because people give up halfway through.
5. Scattered context. Plans in forum topics, discussion in Discord threads and DMs, votes in Discord polls, implementation on-site. Piecing together the full story of any revision is a scavenger hunt.

Why move it on-site?

The revision process, as it exists right now, is a shadow site feature that isn't actually programmed into the website. Fundamentally: the revision process that currently exists is shaped how it is today because it's a workaround.

An on-site revision process is:

• Inclusive. Any registered user can view and comment. Eligible users can vote.
• Transparent. Discussions and votes live in one place, permanently.
• Discoverable. Players who care about a game get notified when someone proposes changes. Game pages show when there's an active proposal.
• Consolidated. The plan, its discussion, and the vote results all live together with a clear audit trail.
• Automated. The system enforces rules (voting periods, thresholds, etc) and executes approved changes where possible. No more checking the docs or a giant flowchart to figure out what step comes next.

Glossary

Term	Definition
Achievement Set Plan	A proposal to create or modify an achievement set. Contains one or more "plan items".
Plan Item	A single proposed change within an achievement set plan (rescore, demotion, retype, transfer, or new achievement).
Plan Claim	When a developer takes responsibility for implementing an approved plan that cannot be auto-executed.
Plan Review	A formal review submitted by a user with a required role, either approving the plan or requesting changes.
Auto-Execute	Automatic application of approved changes without manual developer intervention.

Detailed Design

Data Model

GameAchievementSetPlan

The core plan entity.

id
game_id (FK)
user_id (FK, the plan author)
claimed_by (nullable FK, developer implementing if approved)
claimed_at (nullable datetime)
title (varchar 200, eg: "Rescore challenge achievements")
summary (text, max 5,000 chars - overview of the plan rationale)
state (GameAchievementSetPlanState enum)
allowed_comment_roles (nullable array of role IDs - who can comment on plan items)
is_anonymous (boolean, default false)
required_role_ids (array of FK to auth_roles, computed based on plan items)
role_approvals_complete_at (nullable datetime, set when all required roles have approved)
voting_eligible_at (nullable datetime, 48h after submission for most plans)
voting_started_at (nullable datetime)
voting_ends_at (nullable datetime)
vote_approved_at (nullable datetime)
vote_rejected_at (nullable datetime)
implemented_at (nullable datetime)
closed_at (nullable datetime)
plan_forum_topic_id (nullable FK, topic in "Achievement Set Plans" forum section)
game_forum_topic_comment_id (nullable FK, comment in game's official forum topic)
created_at
updated_at
deleted_at (soft deletes for drafts only)

Note

required_role_ids: Computed on submission by querying plan_item_type_role_requirements for all plan item types present. The plan can't enter voting until all required roles have approved (ie: role_approvals_complete_at is set).

Note

allowed_comment_roles: Controls who can comment on plan items. The plan author can always comment regardless of this setting. If null/empty, anyone can comment. Examples:

• Standard revision plans: [DEVELOPER]
• Junior dev new set proposals: [CODE_REVIEWER] (author + code reviewers only)
• Future player-proposed plans: null (public)

GameAchievementSetPlanItem

Individual achievement changes within a plan. A plan must have at least one item.

id
game_achievement_set_plan_id (FK)
type (PlanItemType enum)
achievement_id (nullable FK, for existing achievement actions)
source_achievement_set_id (nullable FK, for transfers - where it's coming from)
target_achievement_set_id (nullable FK, for transfers or new achievements targeting an existing subset)
proposed_subset_key (nullable varchar, local identifier for grouping items to the same new subset)
proposed_subset_name (nullable, for items targeting a new subset)
proposed_subset_type (nullable, for items targeting a new subset)
proposed_title (nullable, for new achievements)
proposed_description (nullable, for new achievements)
proposed_points (nullable, for rescores or new achievements)
proposed_type (nullable AchievementType, for retypes or new achievements)
current_points (nullable, snapshot at plan creation for rescores)
current_type (nullable AchievementType, snapshot for retypes)
rationale (nullable text, max 2,000 chars - optional justification for this specific change)
order_column (integer, display order within plan)
created_at
updated_at

Note

proposed_subset_key: When targeting a new subset (target_achievement_set_id is null and proposed_subset_key is set), items with the same key are grouped into the same new subset. Only the first item in each group needs proposed_subset_name and proposed_subset_type. Subsequent items inherit those values. This lets a single plan potentially create multiple new subsets. Both Transfer and NewAchievement items can use this field: for example, a plan could transfer 3 existing achievements and propose 2 new achievements all targeting the same new subset.

The current_points and current_type snapshots capture values at plan creation time. At display time, the system compares these snapshots to the achievement's actual current values. If they differ, a warning is shown to inform viewers that the underlying achievement has changed since the plan was created. This keeps voters informed without blocking the plan.

Example display:

Rescore: 50 -> 25 points
⚠️ Current value is now 10 (changed since plan was created)

PlanItemTypeRoleRequirement

Configures which roles must approve plans containing specific item types. This table is managed by RAdmin and drives the dynamic approval requirements. The initial values for this table should be inserted via a DB migration.

id
plan_item_type (PlanItemType enum)
role_id (FK to auth_roles)
created_at
updated_at

Example: if subset transfers require DevCompliance approval, this table would contain:

{ plan_item_type: 'transfer', role_id: 24 }  // 24 = dev-compliance

When a plan is submitted, the system queries this table for all item types in the plan and computes required_role_ids as the union.

Note

A NewAchievement item that targets a non-core achievement set (via target_achievement_set_id or proposed_subset_key) is treated as if the plan also contains a transfer item for the purpose of role requirement lookups. This ensures team review is triggered whenever a plan involves subset creation, even if no existing achievements are being transferred.

GameAchievementSetPlanReview

Tracks formal reviews of a plan, similar to GitHub PR reviews. Any developer can submit a review. Reviews from users with required roles additionally gate the plan from proceeding to voting.

If a plan requires approval from multiple teams and a user leaving a review belongs to all of those teams, they must select which role they're reviewing as when leaving their review. In other words, a user with multiple required roles must submit separate reviews for each role.

id
game_achievement_set_plan_id (FK)
role_id (nullable FK to auth_roles, the role being reviewed as - null for non-gating developer reviews)
user_id (FK to users, the publicly displayed author)
sent_by_id (nullable FK to users, the actual user if posting on behalf of a team account)
verdict (PlanReviewVerdict enum: approved / request_changes)
body (text, required comment explaining the review)
created_at
updated_at

Note

role_id: When a user with a required role submits a review, they specify which role they're reviewing as and role_id is set. Regular developers submit with role_id null (expresses intent but doesn't gate). Reviews with null role_id display grey. Reviews with a role_id display a green checkmark (approve) or red X (request changes).

The user_id / sent_by_id pattern matches existing models like ForumTopicComment and Message:

• user_id is always the publicly displayed author.
• If sent_by_id is null, user_id is the actual author (normal case).
• If sent_by_id is set, user_id is the team account and sent_by_id is who actually wrote it.

A role's current approval status is determined by the most recent review for that role. When the most recent review for all required roles has verdict = approved, the plan's role_approvals_complete_at is set and it can proceed to voting.

GameAchievementSetPlanReviewComment

Item-level comments that are part of a review (or pending submission). This enables GitHub-style review comment batching.

id
game_achievement_set_plan_review_id (nullable FK, null while pending)
game_achievement_set_plan_id (FK, for querying pending comments)
game_achievement_set_plan_item_id (nullable FK, null for plan-level comments within the review)
user_id (FK)
body (text)
created_at
updated_at

Note

review_id: While drafting, comments have review_id = null. On submit, all pending comments from that user for that plan are updated to reference the new review.

Plan Comments

Plan item comments follow the GitHub PR model with a unified input experience and two submission options:

"Comment" button - Posts feedback immediately as a one-off comment. Uses the existing Comment model with CommentableType::GameAchievementSetPlanItem. Good for quick clarifying questions or minor feedback.

"Start a review" button - Adds the comment to a pending review. Uses the GameAchievementSetPlanReviewComment model. The comment remains visible only to the author until they submit their review. Once a user has pending comments, they can continue adding more, then submit the review with a verdict (Approve, Request Changes, or Comment) and an optional overall summary.

On the plan page, both types display together in item threads. Review comments are grouped under their review header showing the verdict and summary.

Users with Role::DEVELOPER can leave comments anonymously. For anonymous comments, user_id is set to a system "Anonymous" account (probably the Server account) while sent_by_id tracks the actual author (visible to RAdmin for moderation).

Warning

Migration required: The comments table needs a new sent_by_id column:

sent_by_id (nullable FK to users, the actual user who wrote the comment)

When sent_by_id is null, user_id is the actual author (existing behavior). When set, user_id is the team account for public display and sent_by_id is who actually wrote it. Existing comments would have sent_by_id = null.

Poll

A generic polling entity, designed to be reusable for achievement set plan votes, icon gauntlets, and future community voting needs.

id
poll_type (PollType enum - what kind of poll this is)
pollable_type (string, eg: 'game_achievement_set_plan', 'game')
pollable_id (integer)
state (PollState enum)
hide_results_until_closed (boolean, default true - if true, results are hidden until voting ends)
results_display_mode (PollResultsDisplayMode enum - controls what's shown after voting)
started_at (datetime)
ends_at (datetime)
created_at
updated_at

Note

Vote visibility: For achievement set plan polls, hide_results_until_closed is true and results_display_mode is percentage_only. During voting, no one sees results. After voting, everyone sees only the final approval percentage, never individual votes.

PollOption

Options available in a poll to be voted on. For achievement set plans, this is just "Approve" and "Reject". For icon gauntlets, options would include images.

id
poll_id (FK)
label (varchar 100)
order_column (integer)
vote_count (integer, denormalized)
created_at
updated_at

Uses spatie/laravel-medialibrary for optional image attachments (eg: icon gauntlet options).

PollVote

Individual votes cast on a poll.

id
poll_id (FK)
poll_option_id (FK)
user_id (FK)
created_at
updated_at
(unique: poll_id + user_id)

Enum Values

PlanReviewVerdict

enum PlanReviewVerdict: string
{
    /** Reviewer approves the plan to proceed. Auto-converts to approve vote. */
    case Approved = 'approved';

    /** Reviewer requests changes before approving. Auto-converts to reject vote. */
    case RequestChanges = 'request_changes';

    /** Reviewer provides feedback without taking a stance. Does not auto-convert to a vote. */
    case Comment = 'comment';
}

GameAchievementSetPlanState

enum GameAchievementSetPlanState: string
{
    /** Plan is being drafted. Unlisted but accessible via direct URL. */
    case Draft = 'draft';

    /** Plan is submitted and open for discussion. */
    case Open = 'open';

    /** Plan requires role approval(s) before voting can begin. */
    case AwaitingApproval = 'awaiting_approval';

    /** Voting is in progress. */
    case Voting = 'voting';

    /** Plan was approved by vote. Awaiting implementation or auto-execution. */
    case Approved = 'approved';

    /** Plan was rejected by vote. Author can edit and reopen. */
    case Rejected = 'rejected';

    /** Plan changes have been implemented. Terminal state. */
    case Implemented = 'implemented';

    /** Plan was withdrawn by author or closed by staff. Terminal state. */
    case Closed = 'closed';
}

State Transitions:

Draft -> Open (author submits, no role approvals required)
Draft -> AwaitingApproval (author submits, role approvals required)
Draft -> Closed (author deletes draft)

Open -> Voting (author starts vote after discussion period)
Open -> AwaitingApproval (author edits plan that requires role approvals)
Open -> Closed (author withdraws)

AwaitingApproval -> Open (all required roles have approved)
AwaitingApproval -> Closed (author withdraws or staff rejects)

Voting -> Open (author cancels active vote)
Voting -> AwaitingApproval (author cancels active vote, plan still needs role approvals)
Voting -> Approved (vote passes, >=60% approve)
Voting -> Rejected (vote fails, <60% approve)

Rejected -> Open (author edits plan and reopens for discussion)
Rejected -> AwaitingApproval (author edits plan that requires role approvals)
Rejected -> Closed (author withdraws)

Approved -> Implemented (auto-executed or claimed dev completes the work)

PlanItemType

enum PlanItemType: string
{
    /** Change an achievement's point value. */
    case Rescore = 'rescore';

    /** Make an achievement no longer unlockable by players (set is_promoted = false). */
    case Demote = 'demote';

    /** Make an achievement unlockable by players (set is_promoted = true). */
    case Promote = 'promote';

    /** Move an achievement between achievement sets (core <-> subset). */
    case Transfer = 'transfer';

    /** Change an achievement's type (progression/win_condition/missable). */
    case Retype = 'retype';

    /** Propose a new achievement to be added to the set. */
    case NewAchievement = 'new_achievement';

    /** Propose changes to an existing achievement's trigger logic. */
    case TriggerAdjustment = 'trigger_adjustment';
}

PollType

enum PollType: string
{
    /** Vote on an achievement set plan (approve/reject). */
    case AchievementSetPlan = 'achievement_set_plan';

    /** Vote on a game's badge image (icon gauntlet). */
    case IconGauntlet = 'icon_gauntlet';

    /** Vote on some question on the home page. */
    case HomePage = 'home_page';

    /** Vote on some question in a forum topic's OP. */
    case ForumTopic = 'forum_topic';
}

PollState

enum PollState: string
{
    /** Poll is active and accepting votes. */
    case Open = 'open';

    /** Voting period has ended. */
    case Closed = 'closed';

    /** Poll was cancelled before completion. */
    case Cancelled = 'cancelled';
}

PollResultsDisplayMode

enum PollResultsDisplayMode: string
{
    /** Show only the winning option and approval percentage. Individual votes never shown. */
    case PercentageOnly = 'percentage_only';

    /** Show vote counts per option. Individual votes never shown. */
    case VoteCounts = 'vote_counts';

    /** Show full details including individual votes (if not anonymous). */
    case Full = 'full';
}

Configuration

Core logic is hardcoded, but timing values and role requirements are configurable.

Site Settings

These values are persisted using spatie/laravel-settings and editable via Filament (filament/spatie-laravel-settings-plugin):

Setting	Default	Description
achievement_set_plans.discussion_period_hours	48	Minimum discussion time before voting can start
achievement_set_plans.voting_period_rescore_hours	24	Voting duration for rescore-only plans
achievement_set_plans.voting_period_standard_hours	72	Voting duration for all other plans
achievement_set_plans.minimum_vote_count	20	Minimum votes required for a valid poll result
achievement_set_plans.review_response_deadline_hours	168	Hours before an unresponsive role auto-approves
achievement_set_plans.approval_threshold_percent	60	Percentage of approve votes needed to pass
achievement_set_plans.approved_plan_expiry_months	12	Months before an unclaimed approved plan expires

Role Requirements

Which roles must approve a plan is determined by the plan_item_type_role_requirements table. RAdmin can configure this without code changes. Example configuration:

Plan Item Type	Required Role
transfer	dev-compliance

With this configuration, any plan containing a transfer item would require approval from someone with the dev-compliance role before voting can begin.

Hardcoded Behavior

The following rules are built into the system and cannot be configured:

• All plans require a discussion period before voting can start.
• Mixed plans use the strictest rules. For example, a plan with rescores and demotions uses the demotion rules.
• Plans without NewAchievement or TriggerAdjustment items can auto-execute. Plans with new achievements or trigger adjustments require a developer to claim and implement them.
• The valid state progressions are fixed.

Plan Type Rules

Given the default configuration, different plan compositions have these requirements:

Plan Contains	Discussion Period	Role Approvals	Voting Period	Auto-Execute
Rescore only	48h	None	24h	Yes
Demotions only	48h	None	72h	Yes
Promotions only	48h	None	72h	Yes
Retypes only	48h	None	72h	Yes
New achievements	48h	None1	72h	No
Trigger adjustments	48h	None	72h	No
Subset transfers	48h	dev-compliance	72h	Yes
Mixed	Strictest applies	Union of required roles	72h	Depends

On submission, the system checks all plan items, looks up required roles, and applies the strictest timing rules. For example, a plan with both rescores and new achievements would need a 48h discussion period, 72h voting, and wouldn't auto-execute.

A plan can auto-execute only if it contains no NewAchievement or TriggerAdjustment items. Plans with transfers can auto-execute because the system can:

1. Create the new achievement set (if targeting a new subset).
2. Attach it to the game with the proposed name and type.
3. Move the achievements to the new set.
4. Transfer existing player unlocks and update all affected denormalized data.

Plans with new achievements or trigger adjustments require manual implementation, since a developer must write the actual trigger logic.

Process Flow

1. Plan Creation

1. Developer navigates to a game page and clicks "Propose Revision".
2. Developer builds the plan:
   • Title and summary explaining the rationale
   • One or more plan items with individual rationales
   • Optional: they may mark the plan as anonymous
3. Plan is saved as Draft. The developer can continue editing as long as they like, or come back later to continue working on their plan.
4. When the developer is ready, they submit their plan.

2. Submission

When a plan is submitted:

1. A new forum topic is created. The topic goes in a new "Achievement Set Plans" forum section. The topic's OP contains a link to the plan page and a summary of the plan's proposed changes.
2. A new forum post in the set's official forum topic is created. This automated post announces the revision proposal and links to the plan.
3. The plan state is automatically set. If the plan requires role approvals, the state becomes AwaitingApproval. Otherwise, the state becomes Open.
4. The discussion timer starts. voting_eligible_at is set to 48 hours from submission. If the plan is in AwaitingApproval, the timer doesn't start until all required roles have approved and the plan moves to Open.

3. Discussion and Review Phase

• The plan is publicly visible on its dedicated page.
• Public discourse about the plan happens in the plan's forum topic.
• Design feedback can be left as comments on the plan page itself - either on specific plan items (like line/code comments on a GitHub PR), or on the plan as a whole.
• If the plan is anonymous, the author can reply anonymously in the forum topic or plan page comments.
• The author can edit the plan during this phase to address developer and/or community feedback. Edits are tracked via spatie/laravel-activitylog, showing a timeline of changes to the plan and its items on the plan page.

Important

If a plan requiring role approvals is edited after receiving approvals, all approvals are invalidated and the plan returns to AwaitingApproval state. Reviewers always approve exactly what goes to vote.

For plans requiring role approvals:
Reviewers with required roles can leave feedback via plan comments and submit formal reviews (Approve or Request Changes) with a required comment explaining the decision. If the author updates the plan, reviewers can submit a new review. The most recent review for each role determines that role's approval status.

Reviews can be submitted as a team account (using the user_id / sent_by_id pattern).

A user with multiple required roles sees separate review options for each role. The plan cannot enter voting until the most recent review for all required roles has verdict = approved.

Review response deadline: When a plan enters AwaitingApproval, each required role has 7 days (configurable via review_response_deadline_hours) to submit a review. A reminder notification is sent to the team at the halfway mark. If a role still hasn't responded by the deadline, the plan auto-advances as if that role approved. This prevents plans from being held up indefinitely by an unresponsive review team.

4. Starting the Vote

The plan author manually triggers voting when:

• For any plan not requiring role approvals: After voting_eligible_at has passed (48h minimum).
• For any plan requiring role approvals: After all required roles have approved.

When voting starts:

1. A Poll is created with "Approve" and "Reject" options.
2. The plan state becomes Voting.
3. voting_ends_at is set (24h for rescore-only plans, 72h otherwise).
4. The plan can no longer be edited.
5. Notifications are sent to eligible voters.

5. Voting

• All developers can vote on any plan.
• Formal reviews from the discussion phase auto-convert to votes when voting starts (see "Plan Reviews" section).
• During voting, no results are visible to anyone, including vote counts.
• After voting ends, only the final percentage is shown. Individual votes are never exposed.
• Voters can change their vote at any time until voting ends.
• The plan author can cancel the vote at any time while the poll is active and running. This returns the plan to the Open state (or AwaitingApproval if it still requires role approvals).

A plan passes if the poll meets the minimum vote count (minimum_vote_count, default 20) and approvals meet the configured threshold (approve_count / (approve_count + reject_count) >= approval_threshold_percent). The default threshold is 60%. Abstentions are not tracked. The minimum vote count may be raised over time as the notification system matures and more developers participate in voting.

If the poll closes without reaching the minimum vote count, it automatically extends once for the same duration (24h for rescore-only, 72h otherwise). If quorum is still not met after the extension, the poll fails with an "Insufficient Votes" outcome and the plan returns to Open state so the author can try again later.

6. Poll Resolution

If approved: The plan state becomes Approved and the game forum topic post is automatically edited to reflect the outcome. If the plan is auto-executable, its changes are applied immediately, its state becomes Implemented, and a completed AchievementSetClaim record is created on behalf of the plan author (ensuring the revision appears in the "Just Released" section on the home page). If the plan is anonymous, the claim record is attributed to either the RAdmin account or the RABot account so the plan author doesn't get doxxed. If the plan is not auto-executable, the plan enters an "approved plans pool" for any developer to claim.

If rejected: The plan state becomes Rejected and the game forum topic post is edited to reflect the outcome.

7. Implementation (Non-Auto Plans)

For approved plans that cannot auto-execute:

1. The plan author has a 1-week priority window to claim the plan. During this window, only the author can claim it.
2. After the priority window expires (or if the author declines), the plan appears in the "Approved Plans Pool" for any developer to claim.
3. claimed_by and claimed_at are set, and an AchievementSetClaim is created.
4. The claiming developer implements the changes.
5. When the developer marks their claim as complete, the plan state automatically becomes Implemented.

Plan claims follow the standard AchievementSetClaim expiration rules. When a claim expires, the plan returns to the approved pool for someone else to claim. Approved plans expire after 12 months (configurable via achievement_set_plans.approved_plan_expiry_months) if no one claims and completes them. RAdmin can also manually close a plan at any time if it becomes irrelevant.

Self-Revisions

If a developer is the sole author of all achievements being modified, no plan is required. They can just make changes directly. But, they can still use the plan system if they want visibility, auto-execution, or a permanent record/diff of the change.

QA Retypes

The QA team can retype achievements on inactive developer sets without a plan, as they do today. An "inactive developer set" is one where all achievement authors are no longer actively contributing to the platform. This avoids bottlenecking QA's existing workflow, which processes 7-10 missable/progression tag reports per week.

Retypes on active developer sets still require a plan and go through the standard process.

Discussion Spaces

Plans have two discussion spaces that serve different purposes:

The plan comments (on the plan page) are for design feedback from developers. These comments can target specific items (like code review comments) or the plan as a whole. This is the working space for technical review. Plan comments are locked once the plan reaches a terminal state. Only developers are allowed to leave plan comments.

The forum topic (in the new "Achievement Set Plans" forum section) is for public discussion. Anyone can participate - players, developers, whoever. The forum topic stays open even after the plan is done.

Basically: plan comments are where developers refine the proposal, and the forum topic is where everyone else talks about it.

Forum Integration

Plan Forum Topic

Each submitted plan gets a dedicated forum topic in a new "Achievement Set Plans" forum section with the following OP structure:

• Title: "[Game Name] - [Plan Title]"
• Body: Auto-generated summary with a link to the plan page
• Author: The plan author (or "Anonymous" if is_anonymous = true)

If a plan is anonymous, the author can reply in the topic anonymously. The system tracks that they are the plan author internally but displays something like "Anonymous (Plan Author)" publicly.

Game Official Forum Topic Post

When a plan is submitted, a post is automatically created in the game's official forum topic:

[b]Revision Proposed:[/b] [Plan Title]

A revision has been proposed for this achievement set.

[url=some-link]View Plan and Discussion[/url]

When the plan reaches a terminal state, this comment is automatically edited:

[b]Revision Proposed:[/b] [Plan Title]

A revision has been proposed for this achievement set.

[b]Status:[/b] ✅ Approved and Implemented

[url=some-link]View Plan and Discussion[/url]

Other possible statuses are: ⏳ Approved - Awaiting Implementation, ❌ Rejected, and 🚫 Closed.

Plan Reviews

The review system works like GitHub PR reviews. Any developer can participate through comments and formal reviews.

Review flow: Developers can batch multiple item comments into a single review. While drafting, comments are pending and only visible to the comment author. When ready, they submit with:

• A verdict: "Approve", "Request Changes", or "Comment".
• An optional overall summary of their review.

On submit, pending comments become part of the review and visible to everyone. Developers can also post one-off comments immediately without starting a review (see "Plan Comments" in the data model).

Verdicts:

• Approve - approves the plan (body optional)
• Request Changes - requests changes before being willing to approve (body required)
• Comment - provides feedback without taking a stance (body required)

Reviews display visual indicators based on the verdict and whether the reviewer has a required role:

• Required role + Approve: green checkmark
• Required role + Request Changes: red X
• Normal developer + Approve: grey checkmark
• Normal developer + Request Changes: grey X

Auto-voting: When voting starts, formal reviews automatically convert to votes. "Approve" reviews become approve votes. "Request Changes" reviews become reject votes. The following do not convert to votes:

• "Comment" reviews (no stance taken)
• Team account reviews (not a real person)

If the plan was edited and reviews were invalidated, auto-votes don't carry forward. Developers can still manually cast or change their vote during voting. Auto-voting is just a convenience.

To change your auto-vote before voting starts, submit a new review with a different verdict. Your most recent review determines your auto-vote.

Team account reviews:

Formal reviews support the user_id / sent_by_id pattern for team-based reviewing. Publicly, the review displays as from the team account. Team members see who actually wrote it. If sent_by_id is null, the review shows as from the user directly.

If the author edits the plan, all reviews become stale and reviewers can submit new ones. The most recent review from each required role determines that role's status. Once all required roles approve, the plan can go to voting.

Team accounts automatically receive an on-site DM from the Server account when a plan is created that is awaiting the team's approval. This facilitates any internal discussion that needs to privately occur before the team leaves their review.

One Plan Per Game

Only one active plan per game is allowed at a time. Trying to create a plan for a game that already has one shows an error with a link to the existing plan. We might relax this later when player-submitted plans are supported.

Note

If multiple "awaiting implementation" plans are eventually supported per game, a conflict resolution strategy will be needed to handle cases where plans propose incompatible changes to the same achievements.

Notifications

This builds on the notification infrastructure from PR 4510.

Defining "Invested Players"

A player is "invested" if any of the following are true:

• They have a current mastery (100% via player_achievement_sets).
• They have at least 1 hour of playtime in the last 6 months (via player_sessions).
• They have commented on an achievement in the set within the last 6 months (via comments).
• They have contributed to the set (authored achievements, contributed artwork, etc).
• They have opted in via a "Watch for revisions" toggle on the game page.

Note

The mastery and playtime criteria may seem redundant, but the playtime check catches players who made significant progress and then reset their progress for some reason. Mastery alone would miss them.

These groups are deduped - no duplicate notifications.

Opt-out model: Mastery holders, recent players, and set contributors are implicitly subscribed. Any user can explicitly opt in via the "Watch for revisions" toggle. Any implicitly-subscribed user can explicitly opt out via the same toggle. Explicit overrides always take precedence, similar to how forum topic subscriptions work. Users can also globally disable all set plan notifications in their notification settings, just like any other notification type.

Implicit subscriptions: Commenting or reviewing on a plan implicitly subscribes you to that plan's notifications, overriding any user-set global opt-out. If they cared enough to participate in the discussion, they should know when the vote starts and how it resolves.

Game Page Indicator

When a game has an active plan (Open, AwaitingApproval, or Voting), the game page shows an indicator linking to it. Players who visit the page can see something's happening even if they didn't get a notification. Past plans (approved, rejected, closed) are also accessible from the game page, providing a history of why changes were made and preventing duplicate proposals.

Notification Events

The system sends notifications for:

Event	Recipients
Plan submitted (no approval needed)	All Role::DEVELOPER users + Invested players (unless retype-only)
Plan submitted (needs approval)	All Role::DEVELOPER users + Users with required roles
Review deadline approaching (halfway)	Users with required roles who haven't reviewed
All required roles approved	Plan author + Invested players (unless retype-only)
Review submitted (Request Changes)	Plan author
Discussion period ended (eligible to vote)	Plan author
Plan enters voting	All Role::DEVELOPER users
Plan approved/rejected	Plan author
Plan implemented	Mastery holders

Access Control

Action	Who Can Perform
Create plan	Any Role::DEVELOPER
Edit own plan	Plan author (while in Draft or Open state)
Comment on plan items	Plan author, or users with a role in allowed_comment_roles (public if null)
Submit review	Users with required roles (per plan_item_type_role_requirements)
Submit plan	Plan author
Start voting	Plan author (when eligible)
Cancel active vote	Plan author
Vote	Any Role::DEVELOPER
Claim approved plan	Any Role::DEVELOPER
Mark plan implemented	Claiming developer
Close own plan	Plan author (before implemented)
Force-close any plan	RAdmin
View draft plans	Anyone with a direct URL
View submitted plans	Any user
Comment on plan forum topic	Any registered user

Example Plan Definitions

Rescore-Only Plan

GameAchievementSetPlan:
    game_id: 1234
    title: "Rebalance point values for consistency"
    summary: |
        Several achievements in this set are compared to similar achievements
        in other games of this same series. This rescore makes the points values
        consistent across all the games.

    # 48h discussion period
    # 24h voting period
    # Auto-executes on approval

PlanItems:
    - type: rescore
      achievement_id: 5551
      current_points: 50
      proposed_points: 25
      rationale: "this is just beating the game, currently overscored"

    - type: rescore
      achievement_id: 5552
      current_points: 10
      proposed_points: 25
      rationale: "this is a really hard and missable challenge, currently underscored"

Subset Transfer Plan

GameAchievementSetPlan:
    game_id: 1234
    title: "Move extreme challenges to subsets"
    summary: |
        The following achievements represent challenges well beyond typical
        mastery expectations. Moving them to dedicated subsets allows
        players to pursue them without blocking a standard mastery.

    # minimum 48h discussion period
    # Requires dev-compliance approval (has transfers)
    # 72h voting period
    # Auto-executes on approval

PlanItems:
    - type: transfer
      achievement_id: 5010
      source_achievement_set_id: 100 # base set
      target_achievement_set_id: null # new subset
      proposed_subset_key: "brutal"
      proposed_subset_name: "[Subset - Brutal Difficulty]"
      proposed_subset_type: "bonus"
      rationale: "This requires a full-game damageless run."

    - type: transfer
      achievement_id: 5011
      source_achievement_set_id: 100
      target_achievement_set_id: null
      proposed_subset_key: "brutal" # same new subset as above
      rationale: "This requires completing the whole game blindfolded with one hand."

    - type: transfer
      achievement_id: 5012
      source_achievement_set_id: 100
      target_achievement_set_id: null
      proposed_subset_key: "speedrun" # different new subset
      proposed_subset_name: "[Subset - Speedrun]"
      proposed_subset_type: "bonus"
      rationale: "This is a sub 1 hour full game speedrun that requires extensive routing."

Mixed Revision Plan

GameAchievementSetPlan:
    game_id: 1234
    title: "Modernize the set and add some missing content"
    summary: |
        This revision adds a missing achievement for a hidden ending,
        demotes a redundant achievement, and sets an achievement to
        missable.

    # 48h discussion period
    # No role approvals required
    # 72h voting period
    # Does not auto-execute (has a new achievement)

PlanItems:
    - type: demote
      achievement_id: 5020
      rationale: "Spam: already covered by another achievement in the set."

    - type: new_achievement
      proposed_title: "True Ending"
      proposed_description: "Witness the game's true ending"
      proposed_points: 25
      proposed_type: "win_condition"
      rationale: "The game has multiple endings, but the best ending isn't covered by an achievement yet"

    - type: retype
      achievement_id: 5025
      current_type: null
      proposed_type: "missable"
      rationale: "This achievement becomes permanently missable after Chapter 3"

Future Considerations

Player Voting on Tiebreakers

Currently, only developers can vote on plans. If quorum or close margins become a recurring problem, one option is to introduce a weighted tiebreaker poll for contentious votes (eg: where the developer vote lands between 50-60%). This secondary poll would be open to a vetted subset of players - such as set contributors, former developers in good standing, or players who have demonstrated knowledge of set design guidelines through other site contributions. Player votes would carry less weight than developer votes, ensuring developers retain final say while giving invested players a meaningful voice in borderline decisions.

Player-Proposed Plans

The Summary mentions allowing players to propose plans in the future. Player-proposed plans would need additional safeguards before reaching a vote, such as a minimum completion threshold on the game (eg: 80% progress), a minimum number of upvotes from other players, or sponsorship from a developer. The exact requirements would be designed once the developer-only system is established and we have data on how the process works in practice.

Footnotes

1. New achievements targeting a non-core set (via target_achievement_set_id or proposed_subset_key) also require team approval, similar to subset transfers. ↩

[Hexadigital]

This looks good to me - it might have to be a broader discussion outside of this RFC, but if we're streamlining the process, I wonder if it would be worth requiring the same discussion and vote time for rescores and self-revisions (if it has been more than 30 days since the dev's last claim)?

Particularly with

Rescore-only plans skip discussion and can proceed directly to voting.

listed as hardcoded behavior - since at the moment, we have devs opening discussions for rescores (like the recent rescore proposal for DDRMAX2), and when the player-submitted rescore thread was running, I believe most of those that were sponsored by a dev also went up for discussion.

Likewise for self-revisions - if a dev just released a set/revision and needs a new revision claim to fix or add something that got overlooked, we don't want to block that, but for cases like a set having existed for a year and a dev wanting to halve/double the points, or a hack being updated to the latest version and achievements being added/removed as a result, it would be good to get some input from devs and players on those.

[redwizard42]

Yeah, I think a non-timed discussion period for rescores would be more in line with the current revision rules. Let it enter into the discussion phase, but don't put a duration requirement before the proposer can start a vote. (But arguably maybe we should just add in a discussion timeframe because every so often rescores get contentious and it's not obvious they are possibly problematic until after voting has started)

[suspect15]

I think it's probably the most streamlined to just make the rescore proposal have a 48 hour discussion period like the revisions. It's not an urgency matter, and will give some more time for people to discuss and make a potentially more informed vote.

[wescopeland]

RFC update: rescore-only plans now have a 48h discussion period like everything else. The shorter 24h voting window is kept since rescores are lower-impact than structural changes, but they'll now get the same discussion time.

[Jamiras]

A player is "invested" if they have a current mastery (100% via player_achievement_sets), OR have played the game in the last 6 months (via player_sessions), OR have opted in via a "Watch for revisions" toggle on the game page.

What constitutes "played the game"? Is loading the game enough? A minimum amount of playtime? A minimum number of achievements unlocked?

I would also include anyone who has contributed to the set (achievements, artwork, etc) even if they don't have recent playtime or a mastery. Maybe they should just be automatically opted in to "watch for revisions" so they can explicitly opt out.

Can people who have mastered the game opt out? Will this be like subscriptions where there's an implicit set with explicit overrides?

Notifications are sent to eligible voters.

Any registered user can view and comment. Eligible users can vote.

What constitutes "eligible voters"? Is it just "invested" + "all developers"? How does a player become eligible after the revision is proposed so they can vote?

[Hexadigital]

I forgot who mentioned it and where, but I think I saw someone say that "the number of new players in a hour is more than the number of active devs", which would imply that devs have no voice in revision votes that include players solely due to being so vastly outnumbered.

If we wanted to include player voting somehow, I'd be in favour of having relevant players be the decision maker for any contentious votes (where the "winning" dev vote is between 50-60%), but having devs be the sole voters in the 99% of revision votes that aren't contentious. This could be implemented as a separate type of "tie breaker" poll that only allows relevant players to vote, and is automatically created (and automatically notifies relevant players) if the margin on the dev revision vote is too small.

[ladynadiad]

I would be in favor of allowing some players to actually vote. I'd suggest something along the lines of players being vetted to have shown care for the site and a knowledge of guidelines. Some players that could be included that would likely be an overall benefit would be:

1. Former devs who resigned and are in good standing otherwise and would be able to return to being a full dev.
2. Jr devs who have published one or more sets of good quality and are nearing graduation.
3. Non-dev members of teams such as playtesters, art team, events team, and writers. These players have shown a wish to improve the site and many of them are familiar with set design and guidelines from working with devs.
4. Players who are generally helpful with tickets and go above and beyond to help the dev resolve the issue and generally show they care about more than just getting their own unlock.
5. Players who have provided helpful critique in forums and have shown favor for revisions that have been approved.
6. Players who have reported UWCs in the past and provide DevComp with helpful reports that show they understand UWCs.
7. Many event regulars, especially those who participate in events besides AOTW and are active in the event channels on discord. A lot of the regulars for events clearly care about more than points and provide awesome information to help improve sets they played for an event. Some of these players have even inspired a revision or written up something that a dev sponsored as a revision.
8. Players who participated in Devember or House Cleaning and have earned a badge. Helping with resolving tickets they didn't even open is very rare for players to do and the players who did so clearly care about improving the site.

I'm sure most devs can think of some players that would fall into one or more of these groups and whose voice would be a benefit. There are many non-devs who have contributed something besides complaining and negativity. I agree that the majority of players have no business voting for a revision, but I do think some have as much knowledge of set design and guidelines as devs do and care about more than just their own points.

[Nepiki]

If players were to be included, an alternative would be if they had a ''piece of the chart''. Let's say a revision or subset needs 60% to pass, as it currently is, and 75% of the weigh is distributed to developers, and 25% to users:

• 15 out of 25 developers say yes. This would make it 60%, within the overall vote it would be 45%. So to pass, it would need 15% additional votes.
• 9 out of 10 users say yes. This would make it 90%, within the overall vote it would be 22.5%. Adding them up to another, the votes end up being 67.5% yes.

This would mean that developers will always have the complete ability to approve- or reject something. At the same time, players could make the difference between something passing and not passing.

[wescopeland]

RFC update: I've made several changes based on this discussion thread's feedback.

Invested players
The definition now includes set contributors (achievement authors, artwork contributors, etc) who are implicitly subscribed but can opt out. The "recent player" threshold has also been tightened from "having booted the game" to having at least 1 hour of playtime in the last 6 months. This avoids notifying someone who booted the game for a few seconds and never came back, but still catches players who played a while and maybe even reset their progress. The whole thing also works like other notifiable types: it's implicit and supports explicit overrides. Users can globally disable all set plan notifications in their settings.

Quorum
I've added a configurable minimum vote count (starting at a very conservative 20). If a poll closes without enough votes, it extends once for the same duration as the original poll. If quorum still isn't met, the poll fails and the plan returns to Open status so the author can try again later if they want. We should raise the 20 minimum vote count over time as the new notification system matures - we don't have any workable data right now to predict what the default minimum should be.

Player voting
For now, I've kept things as developer-only to try to limit the blast radius of the code changes involved in this RFC. However, I've added a new "Future Considerations" section which talks about weighted tiebreaker polls for contentious results, open to a vetted subset of players along the lines of what ladynadiad and Nepiki have described. This is worth revisiting once we have real data on what voter turnout will look like with a new system.

[suspect15]

If players were to be included, an alternative would be if they had a ''piece of the chart''. Let's say a revision or subset needs 60% to pass, as it currently is, and 75% of the weigh is distributed to developers, and 25% to users:

• 15 out of 25 developers say yes. This would make it 60%, within the overall vote it would be 45%. So to pass, it would need 15% additional votes.
• 9 out of 10 users say yes. This would make it 90%, within the overall vote it would be 22.5%. Adding them up to another, the votes end up being 67.5% yes.

This would mean that developers will always have the complete ability to approve- or reject something. At the same time, players could make the difference between something passing and not passing.

This is an interesting idea that is definitely worth further exploration at some point. There are certainly some players whose perspectives are informed, enterprise-level, and would make good decisions. The real issue with player votes is that many of them are motivated by self-interest and that is at direct odds with the purpose of a revision. It's simply not acceptable to allow someone to vote for what's best for a set whose criteria considers whether they feel like replaying a game or not. It's an extremely flagrant conflict of interest.

The only way to remove self-interest votes is to remove the the population that wholly contains the demographic that votes that way, even though it's not everyone in the player population. Admittedly, there are for sure objectively minded players, but I don't really think their votes add any value that the trained dev team already doesn't provide.

[Doomhiker1]

I like this plan, broadly speaking. However, I question if simple retying only revisions should require a plan, notifications, etc. Retyping, unlike other revisions, just does not affect player experience at all. More importantly, most retyping are objective fixes, don't usually because of improper marking (usually from when markers were first added, as not all games were marked accurately when people were just trying to properly mark as many games as possible). It's rarely a subjective thing like most other revisions, so I don't believe it needs a rigorous process or notification.

I also don't think all players who played a set should be instantly notified, just because it is not uncommon for a player to boot up a game, earn a single cheev, and never touch it again. I'd say that ~20% of the set should be earned for a player to be notified, just to avoid players who didn't spend too much time on a game being annoyed by it.

[redwizard42]

We have revision rules for type changes though, so it should be included.

[suspect15]

We probably need to relook at that policy. QA usually gets 7-10 missable tag reports a week which is not something that it has the manpower to do a revision for each one. The vast majority of them are no brainers and almost always in sets that already have other missables marked. I can't recall offhand a single dev proposed revision to add missable tags to a set, so I don't think the rule is beneficial. Perhaps it would be best to just offload tagging responsibility of inactive dev sets entirely to QA.

[redwizard42]

I mean, it's fine if they are inactive dev without typing.

[Hexadigital]

Yeah, QA already has permission for setting tags on inactive dev achievements - but whenever someone has wanted to modify an active dev's typing, it had to go through a revision.

[wescopeland]

RFC update: I've made several changes based on this discussion thread's feedback.

QA retypes
I've added a carve-out for this in the latest version of the RFC. The QA team can continue retyping inactive developer sets without any plan, just like today. Retypes on active dev sets will still go through the plan process.

Retype-only notifications
Retype-only plans will now skip notifying invested players entirely, since retypes don't move the needle much on player experience. Developers will still get notified when voting starts, and the game page indicator will still be visible for anyone who wants to find the plan.

[Nepiki]

A few of my thoughts on the RFC and the future or how revisions/subsets are handled, most that we have already discussed in private channels:

1. Having a "request proposal/subset" button on game pages is a massive improvement to streamlining the process. The way I envision it is a pop-up dialogue opens where the player/developer can input everything necessary for a proposal, then it is sent to a team who approves it or requests more feedback. If approved, it will automatically create a discussion place (and potentially a poll) so that the player/developer doesn't need to do anything beyond watching the conversation and act on the result. My additional thoughts are:
   • The pop-up dialogue would need to enforce some minimum-provided data to ensure the reviewing team can actually approve it without needing to spend hours researching on their own that could have been prevented. It would be unreasonable for them to ask more feedback from the proposer when they provided the absolute minimum, like "This set has damageless and I don't like so they should be in a subset".
   • Rescores/revisions probably wouldn't have to go through a team, and just automatically creates the discussion space. That barrier currently doesn't exist, and I'm not sure if we want to create additional barriers.
   • I think it would be beneficial to have an ''auto-approve'' if the team does not reach a conclusion in x time to speed up the process and not keep players/developers waiting for long. This could be 3 days/1 week for dev requests, but far longer for player requests due to the amount of research that needs to be done.
2. This is beyond the scope of what the initial RFC requests, but having the community involved would be fantastic but there need to be a few limitations.
   • Developers have no limitations as they are trained in set design. They can click the button at any time, discuss at any time, and vote at any time.
   • Players would not be able to click the button until they have reached a certain threshold. Could be ~80% progress on a set, could be having at least x points. This ensures the player starting the proposal can be trusted with knowledge of the game to make a proposal. I think the people who can discuss could probably be slightly stricter too, e.g. only people who have made progress in the past month or have it beaten/mastered. Voting I agree they probably shouldn't have access to though BUT it would be interesting data to have. I know voting but not having any weight doesn't sound appealing, but it might be fun data to compare with what the developers think.
3. It would be good to have the discussions and proposals archived somewhere on the game's page, so people can look into it and understand why something was approved/rejected. Of course, we could make it so all users have their pfp and name removed to enforce anonymity. This ensures that everyone is aware of proposals and doesn't make them again. We could probably make it that proposals do expire so they can be made again in the far future as the landscape of RA keeps involving. It's probably then also a good idea to abandon all currently-rejected subsets and give them another chance--if they truly are still bad ideas, they would get voted against on the poll anyway.

Those are some of my main thoughts written out. I'm definitely excited for seeing this become a reality because it addresses many pain points within both the player- and developer community, including lack of transparency and the community not having enough weight in the decisions made. It has been made clear over the past months that people are not very satisfied with how the current process works, for completely unique reasons, and this could tackle a lot of them all at once.

[wescopeland]

RFC update: I've made several changes based on your feedback, @Nepiki.

Review deadlines
Plans requiring role approvals now have a 7-day response deadline (this is also a new configurable setting by RAdmin, so we can change it without needing to make any code changes). Teams will get a notification reminder at the halfway mark if a plan is still waiting on their approval. If a role hasn't left a review by the deadline, the plan will now auto-advance. This means plans can't be stuck forever in limbo.

Game page history
Past plans (approved, rejected, closed, abandoned, etc) are now accessible from the game page (it'd be a new subpage), not just active ones. This gives interested readers context on why changes were made and prevents duplicate proposals that would gum up the system.

Player-proposed plans
I've added this to the new Future Considerations section. The exact safeguards will need to be designed once we have data from how the developer-only system works in this grand experiment.

[Hexadigital]

While I like the idea of a minimum vote count / quorum, I'm not sure how well it would work in practice, as it provides a barrier to revisions that the plan proposer can't do anything about.

For example, with a minimum vote count of 20:

1. Revision poll ends with a vote of 16-0 in favour - it doesn't pass, but there's nothing the proposer can do to get more devs to show up / vote.
2. Revision poll ends with a vote of 16-4 in favour - it passes, despite having the same number of people for it and more people against it than the previous.

Given how wildly voting turnout can vary, as can be seen in the current revision votes, I'm not sure what the best way to handle this is without knowing why some devs selectively vote - if it's a matter of the game in question then there's not much that can be done about it, but if it's a matter of "the plan was unclear so I didn't vote", then maybe the voting page could use some encouragement to vote against any proposal that is unclear, so it can be better refined.

[wescopeland]

Thanks for your continued feedback and thoughts on this!

I'm afraid the 16-0 vs 16-4 framing might miss what the floor is accomplishing. My sense is @Jamiras was concerned about ensuring legitimacy through participation. Without any kind of floor, we could have a plan pass 2-1 with only 3 developers voting. This clearly isn't representative of the community. The quorum certainly doesn't create a perfect approval metric, but it does prevent this stated problem from ever occurring.

If quorum isn't met, the poll auto-extends once for the same duration. If it still doesn't hit the floor, the plan returns to Open so the author can revise it or try again - it's not a total dead end. And the quorum number itself isn't set in stone: 20 is a starting point that can be tuned once there's real data to tune against.

In this new paradigm, I don't think encouraging rejection votes on unclear proposals will be the right move. We don't want people casting "reject" as a proxy for "I don't understand this". If a proposal is unclear, this should be addressed by discussion during the review phase rather than inflated rejection numbers. The review phase exists specifically for that kind of transparent feedback loop.

I want to underscore: the current Discord poll turnout isn't comparable to what this system will have. This design includes targeted notifications to every developer when voting starts - a fundamentally different engagement model. My vibe is participation will be higher and more consistent, but we won't know until it's live, so it's really important that the quorum floor is a configurable setting.

[ladynadiad]

One idea also could be to only require a quorum if the set has more than a specific amount of players, maybe something that could allow for that to change as the site grows. Current all time high players online actually could be a solid metric to work from. It's 6625 right now, 10% of that would be a set with 663 or more players. 5% would be 331 players. We probably would want to have a very bare minimum to ensure it's not passing with a small number of devs, but something like 10 should suffice.

In general I find the most common factor that limits votes is how well do devs know the game. Obviously it can be hard to feel confident in voting for something for a game you don't know and for all you know the plan could actually be terrible but sounds good on paper. I have noticed though that the dev proposing the revision having a solid track record can help, as can the contents of the plan itself since simple revisions like fleshing out progression, fixing tags, and similar tends to be straightforward and nearly always pass with a reasonable amount of votes.

[StingX2]

"They have at least 1 hour of playtime in the last 6 months (via player_sessions)."

Will this account for playtime PRIOR to the proposal, or are you opening up a series of alts and trolls to load a game to derail conversation?

[wescopeland]

Will this account for playtime PRIOR to the proposal

Yes.

are you opening up a series of alts and trolls to load a game to derail conversation?

Any type of intentional derailment will be aggressively moderated.

[christianlegge]

First of all, I love this idea and I'm already super excited to see it on the site. We definitely need to move away from Discord for this - not necessarily because of what's been happening with Discord, although it doesn't help - primarily, I just agree that the decentralization is a problem. I think most of this is fantastic. Here's what I would say for feedback:

• I'm confused about the flow to propose a new subset. It's great that the same action can get both DevComp review and the approval vote at once. But "Transferring existing achievements to/from subsets (including proposing entirely new subsets)" is confusing - what if the new subset is to contain new achievements? Can a new subset still be proposed this way? Would it still have to be marked as a transfer, or can a revision vote proposing new achievements target a currently-nonexistent set as well?
• GameAchievementSetPlanItem should also include a current_description field so that things can be kept straight across revisions which change trigger conditions conceptually.
• Is Rejected a terminal state for GameAchievementSetPlanState? It's not listed as one, but there are also no transitions from it. Is it going to be possible for a proposal to stay open and be modified/re-polled in the event of a vote rejection?
• I'm not against the idea of players voting in general, but I would push back on the "tiebreaker" concept. The idea behind 60% approval, at least how I see it, is that a significant enough majority need to be in favor of the change that it can't just be easily reverted with another vote in the future. A vote that just barely misses the threshold shouldn't be pushed over by a tiebreaker, because that's a sign that it's too close to be confidently executed.
• Developers who are opted out of poll notifications should still receive them in cases where they have commented on the discussion, and should also by default receive notifications when a proposal is submitted, also opt-out. To be more in line with the current Discord role situation, rescores should have a separate setting here, but I don't really think that's necessary to bring into the new system.
• "Invested players" should include players who previously mastered a game and no longer have 100% due to achievements being added.
• The top of the RFC says "Inclusive. Any registered user can view and comment" but I see there was discussion about this and that it later says the plan comments are a technical space for developers to discuss. To what extent will that discussion be public? Broadly, I think it's a bad idea to remove private dev discussion entirely.
• Similarly, I don't agree with the ability to add anonymous comments. Maybe if the discussion is publicly viewable then it would be useful to tag a comment as anonymous to players, but I don't think it's helpful to discussion to anonymize them privately, and in fact I think it actively harms discussion to not know who's giving feedback. Obviously they'd still be tied to your account on the backend so people can't use them to be nasty, but still, I don't see a benefit that outweighs the drawback. Anonymous proposals I can understand, but for feedback comments I don't think it's the same.
  • To elaborate here, I do understand the idea that feedback should stand on its own merits and so it shouldn't matter who gives it. But to present an option for anonymity, the act of choosing that option communicates something as well. Crazy as it sounds, I would be more in favor of forcing all comments to be anonymous on revisions than I would for opt-in; but I still don't prefer that over regular, non-anonymized discussion.

[wescopeland]

Hi @christianlegge! Thanks for your feedback. I'll try my best to address each point below. Additionally, I've just published a version 1.2 of the RFC that contains edits based on your feedback.

I'm confused about the flow to propose a new subset. It's great that the same action can get both DevComp review and the approval vote at once. But "Transferring existing achievements to/from subsets (including proposing entirely new subsets)" is confusing - what if the new subset is to contain new achievements? Can a new subset still be proposed this way? Would it still have to be marked as a transfer, or can a revision vote proposing new achievements target a currently-nonexistent set as well?

You're right that there's a significant gap in the current design. Under the 1.1 draft, there's no way to propose a brand new subset containing new achievements. Transfers required an existing achievement to move, and new achievements had no way to target a subset.

The 1.2 RFC contains updates so that NewAchievement items can use subset targeting, and a single plan can mix transfers and new achievements all targeting the same new subset.

Team review still triggers whenever a plan involves subset creation, even if no existing achievements are being transferred.

GameAchievementSetPlanItem should also include a current_description field so that things can be kept straight across revisions which change trigger conditions conceptually.

The rationale field should already cover this. The plan author should explain something like "I'm changing this from 'do X' to 'do Y' for this reason".

Is Rejected a terminal state for GameAchievementSetPlanState? It's not listed as one, but there are also no transitions from it. Is it going to be possible for a proposal to stay open and be modified/re-polled in the event of a vote rejection?

You're right that it's ambiguous. This is intentional: the author can edit the plan, reopen it, and try again. This has the advantage of keeping all the discussion context in one place regarding the previous rejection. If it's a terminal state, this all gets blown away in the new follow-up plan.

For clarity, the 1.2 RFC contains an update showing the possible state transitions from Rejected.

I'm not against the idea of players voting in general, but I would push back on the "tiebreaker" concept. The idea behind 60% approval, at least how I see it, is that a significant enough majority need to be in favor of the change that it can't just be easily reverted with another vote in the future. A vote that just barely misses the threshold shouldn't be pushed over by a tiebreaker, because that's a sign that it's too close to be confidently executed.

I personally agree with you. Player voting of any form on achievement set plans will not be implemented as part of this RFC. The door is simply left open for future discussion.

Developers who are opted out of poll notifications should still receive them in cases where they have commented on the discussion, and should also by default receive notifications when a proposal is submitted, also opt-out. To be more in line with the current Discord role situation, rescores should have a separate setting here, but I don't really think that's necessary to bring into the new system.

I agree with all this feedback. The 1.2 RFC contains these changes to address it:

1. When a plan is submitted, all Role::DEVELOPER users will also receive a notification.
2. Commenting or reviewing a plan will now implicitly subscribe the user to that plan's notifications. Someone who cares enough to participate in a discussion should know when the vote starts and how it resolves.

"Invested players" should include players who previously mastered a game and no longer have 100% due to achievements being added.

I think the current net is probably wide enough. This implies someone who masters a set 5 years ago when it may have looked radically different should be getting these notifications - IMHO I don't think we should go that far.

The top of the RFC says "Inclusive. Any registered user can view and comment" but I see there was discussion about this and that it later says the plan comments are a technical space for developers to discuss. To what extent will that discussion be public? Broadly, I think it's a bad idea to remove private dev discussion entirely.

The RFC specifies two discussion spaces: plan comments (only devs can write, but they're publicly readable) and a dedicated forum topic (fully public read+write).

The "inclusive" line refers to the forum topic. Plan comments restrict who can write but not who can read. Some private discussion is also accounted for: team accounts get a DM for internal deliberation before they leave a review. General dev-to-dev discussion on plan items is public, just like discussion on a GitHub PR.

I don't agree with the ability to add anonymous comments.

If someone proposes a plan anonymously, but comments still show their username, that anonymity is rendered meaningless. Maybe a healthy medium is anonymous commenting is only available to the plan author on their own anonymous plan. What do you think?

[christianlegge]

Thanks so much Wes!

The rationale field should already cover this. The plan author should explain something like "I'm changing this from 'do X' to 'do Y' for this reason".

Sure, that makes sense. I'm not sure if it will be explained thoroughly enough in all cases that no meaning is lost if the achievement changes, but it will make the potential issues even rarer, and it was already a fairly uncommon scenario. Probably not worth storing that extra data for every single item.

The "inclusive" line refers to the forum topic. Plan comments restrict who can write but not who can read. Some private discussion is also accounted for: team accounts get a DM for internal deliberation before they leave a review. General dev-to-dev discussion on plan items is public, just like discussion on a GitHub PR.

One thing I can see happening is that players will treat the public forum as an extension of the dev discussion, responding point-by-point to comments that, under the current system, are meant to be private. Is this the intended outcome? I guess at a certain point I don't see the benefit of the read-only discussion at all in favor of letting players comment in the discussion itself. If PlayerX makes a good point in the forum responding to a dev discussion, then it will either be ignored, rendering it pointless, or devs in the discussion will reference it ("Like PlayerX said..."), at which point they might as well participate directly. I'm willing to be open-minded towards it though, and it may end up working out nicely.

It doesn't affect me at this point since I'm no longer CR, but it would also be nice to have these bespoke discussion posts extended to that private team deliberation rather than it being handled through a site DM (and subsequently Discord for the discussion). That's likely a roadmap feature though and not critical to the proposal.

If someone proposes a plan anonymously, but comments still show their username, that anonymity is rendered meaningless. Maybe a healthy medium is anonymous commenting is only available to the plan author on their own anonymous plan. What do you think?

Yes, to clarify, if anonymous proposals exist, anonymous proposers should be able to comment on their own proposals anonymously. In fact, they should probably only be allowed to do so, because otherwise they could un-anonymize and comment as if they're not the person who proposed it, feigning more community support than there might actually be.

[blueYOSHI9000]

Can regular polls be made for discussion purposes or is there only the definitive approve/reject poll? (Sorry if I missed this while reading!) Because I think it can be really useful as a dev to create a poll with a couple options for how the revision should be done. Ideally you could even incorporate multiple options into the final deciding poll, though I imagine that'd be a good bit more complex so regular polls during discussion would definitely suffice.

[wescopeland]

Hi @blueYOSHI9000 👋

Thanks for your feedback. The Poll model is generic enough we could support this later, but straw polls are currently out of scope for the RFC. It's likely to be implemented separately though at a later date.

[rgavril]

I'm a new developer working on my first revision. I can't offer many insights on improvements yet since I lack first-hand experience with the full revision process. Even so, there are some things I appreciate that are currently missing.

In my experience, few players use the forums. Most prefer the game page comments, where notifications only reach those who have already posted. Making it easier to engage the community is a necessary fix.

Even without a vote, players provide informed opinions that help eligible voters make better decisions. As a developer, I find it hard to vote on unfamiliar games. Player insights would help me feel confident enough to vote instead of abstaining, which would also help reach quorum.

A valuable addition to "Invested Players" would be anyone who has commented on the affected achievements. Since unfair achievements usually have active comment sections, these players are already engaged and likely have relevant feedback.

I also appreciate the plan for a standardized way to list changes. Currently, it is difficult for me to document a revision clearly without the plan becoming hard to follow.

You're doing fantastic work!

[wescopeland]

Hi @rgavril 👋

Thanks for your feedback. Your perspective is certainly useful here.

I agree that achievement commenters should be considered as invested players. The latest version of the RFC (v1.3) has made this adjustment. Anyone who has commented on an achievement in the set within the last 6 months now qualifies as being an "invested player" and will get notified when a plan is proposed.

You're right that most players aren't hanging out in the forums. The real engagement driver is the notifications system which gets those invested players onto the topic to leave their feedback. They probably won't find the plan just by casually browsing the forum. Also, the forum topic is open to everyone, so non-voting users can still share their perspective there. The plan page will link to the forum topic, so developers can always reference that context before voting. This is probably sufficient for now, but something worth keeping an eye on.

[Kinglink]

I'm going to be indelicate about this, but normal (even mastery) players deserve NO vote. Players have really awful opinions on what should and shouldn't be allowed, some players think no change will be a good change, some players think certain achievements should and should not be allowed. No player will vote for lower rescoring for instance.

Players have invested interest that are not about "making a better set" but more importantly players think their opinion of how RA should work is the correct one, and have no understanding about some limitations, or even the rules. (Hell the number of people who think main sets should be just 100 percenting a game is ludicrous and any optional challenge shouldn't be allowed)

Suppose I propose a revision but a player thinks damageless achievements are ALWAYS bad, (Which a decent amount of players do) if I have damageless achievements even though they are good achievements, that revision will never get through.

Now people are already saying "we'll vet players" Nah, that's just a bad idea... I don't think only Devs deserve a say, but the voting will be bad if we allow players whims to change votes no matter the level of "investment" they have in a specific game.

Like I said, I don't think "Dev only" Is the correct option. I propose we open it to " all roles". If you're a Confirmed tester if you're a certified art team member, if you're a writer. Have Guide writers get this privilege. This means contributing to the site in a meaningful way outside of "playing games". Each role can figure out rules. Jr. Devs for instance probably shouldn't vote until they understand how to make sets. Maybe only Artists who have completed the artquest can vote. Each role can decide what's the line. Perhaps if a tester doesn't test for 3 months, they lose their voting privilege. That also incentivize people to contribute to the site.

And this doesn't mean we can't add roles. For those who submit a large number of tickets or created guides, but I'd recommend not making it based on the content of contributions (if we think they're adding good criticism or what not.) Make it based on actual actions we can see. ( X amount of submitted tickets that end up resolved, rather than if someone in charge thinks they wrote a good ticket. Less subjective applications.)

If someone wants to be a participant in this, they can test 1 game a month or a quarter to get the permission. Or write 1 guide every three months... Point being if you want to be a part of this, you can be, but there should be a higher bar than just playing a game.

Similarly "Suggesting revisions" I think there can be something where a player makes a revision request, but MUST have a developer approval. If we don't do that? We're going to have 50 revision requests... a day. Again "I don't like damageless, let's demote it" I guarantee with in 30 seconds of this change, many of those revisions will be made. We can limit it, but I think it'd be better to have a dev sign off. Maybe have a user create a proposal only they can see (or only if they share a link) and a dev can give it a check mark if they agree. Or perhaps again limit this ability to "all roles" but the general public able to make revision plans will create havoc, and a lot of really bad plans.

Note: I'm not saying limit their visibility, or voice, they can complain about a revision but they really shouldn't have a say in the revision , without going through something that assists the site.

they may mark the plan as anonymous

just want to say, love this option. I almost want to say that it should be on by default. Doesn't matter who is making the revision plan outside of the original author, judge it based on the plan not the person.

Give the author the ability to speak as himself or as the "Author" but leave it anonymous. Admins should be able to see who it is, but I think it's better that we aren't influenced by who is making the revision. Is there any benefit from seeing that I submitted a revision if I'm not the original author?

People can out themselves, but I think by default the expectation is the Author should attempt to remain anonymous on proposals.

Edit: Also a plan creator should have a 1-2 day period where they can claim their approved revision plan, before the general developer list gets a crack at it. At least if the plan's creator was a developer. They don't HAVE to pick up the plan, but if I made a plan I'm passionate about, The revision is approved, and I turn around and someone else is trying to implement it, that would feel off, you know? I did the work to set it up, I should get first choice on if I do it.

Similarly how do we know if achievements are even possible? Let's say someone suggests they want to add an achievement for X, but for what ever reason X isn't available in the memory, does that approve plan just die there?

Also for Self-Revisions... Are we saying they can be auto approved with out a vote? Or if someone uses this, the comment period/vote period must happen? I like the idea I can document changes of what and why, but if using this system I am forced to go through comment/voting, I don't see a reason to do self-revisions. (It should be able to bypass the vote, and the comment is just to get feedback, basically if it's self-revision, give them the ability to "Auto approve" but still have a revision forum post.)

Overall though, this is a huge step forward in a lot of ways.

[wescopeland]

Hi @Kinglink 👋

Thanks for your detailed feedback. There's a lot to dig into here, I'll do the best I can:

On player voting
The RFC right now already keeps voting as developer-only. Players can comment in the forum topic and share their perspective, but they don't get a vote. The "Future Considerations" section mentions the possibility of a weighted tiebreaker poll for contentious results, but even that would be limited to a vetted subset and would carry less weight than developer votes. Your "all roles" idea is interesting, and I like it because it ties voting rights to demonstrated site contribution. I think that's an idea worth revisiting.

On player-proposed plans
This is also listed under "Future Considerations" and explicitly called out that safeguards would be needed if we support this. I share your concern about the floodgate problem - we'd design exact guardrails later. We need to first see how the developer-only system pans out in practice. We simply don't have enough data to go by right now to see this far ahead.

On stuff being anonymous by default
I hear your argument for reducing bias, and I think you may be right in there being real value in judging a plan on its merits rather than who submitted it. With that said, I'm hesitant to make this the default. We've already gotten other feedback on this RFC that says it shouldn't even be an option at all except for the plan submitter.

On claim priority for plan creators
This is implied but should be explicit. The v1.3 RFC now includes a 1 week window.

On technical feasibility concerns
Plans with new achievements only describe the design of those new achievements (title, description, points, and type). They don't include any trigger logic. The developer who claims the plan is the one who figures out if it's technically possible. If it turns out an achievement can't be built as described, the developer could abandon the claim. The plan could then be revised or closed.

On self-revisions
The RFC already says if you're the sole author of all achievements being modified, no plan is required at all. You make your changes directly, just the same as today. There's no scenario where using the plan system for a self-revision forces you into a vote you don't want.

[Hexadigital]

Quick question since dizzykei brought it up on a game wall:

They have a current mastery (100% via player_achievement_sets)

Does this include completions (softcore masteries) as well?

[Hexadigital]

Based off seeing how recent revision discussions have gone, I'd like to propose that the revision form has the author being anonymous by default - that will encourage revision discussions being about the proposal itself, rather than any bias for/against the author (and mitigating risk of railroading/brigading resulting in a lower quality discussion as a result).

[Hexadigital]

The Summary mentions allowing players to propose plans in the future. (...) The exact requirements would be designed once the developer-only system is established and we have data on how the process works in practice.

Something to think about during the initial design, unless it's already present and I missed it - it would be good to have access gating based off the type of plan. For example, I could see rescores being a good first test of player-proposed plans (like the community rescore proposal thread we have today), and so it would be useful if players could be allowed to propose those without being able to propose full revisions that add/modify/remove achievements.