When someone presses “Resolved” on a fault report, other readers may not know the basis for that judgment. Previously, that one button removed the report from the unresolved list. Delta instead organizes problems by installed game and stores account-linked fixed, continuing and incorrect-report votes. Status can then take several observations and elapsed time into account.

The original resolved button and on-site checks

The fault reports introduced last July displayed descriptions at the top of an arcade and let anyone report normal operation. Notices could be removed promptly, but one person’s confirmation was also the decision to dismiss them. There was no process for evaluating other visitors’ observations together.

Readers also had to find the affected game in the description. At a large arcade, each person needed to determine whether the report concerned the same equipment. We therefore made authors select an installed game, describe the problem and its impact, and let later visitors respond to its condition.

flowchart TD
    accTitle: From a resolved button to vote-based decisions
    accDescr: Previously a resolved button changed status directly; the new structure records account-linked votes and lets server rules decide closure.
    O["Before: press Resolved"] --> P["Immediately leave unresolved list"]
    N["After: game-specific report"] --> V["Fixed, continuing, incorrect-report votes"]
    V --> S["Account records and server decision"]
    S --> R["Apply resulting status"]

Game-specific reports and photographs

A game-specific report selects an entry at the venue and describes whether play is impossible or how it is affected. The server checks that the entry belongs to that arcade and saves the report and relationship together. Current problems can then be attached to games without changing their inventory.

A fault photo and impact linked to game information, with fixed, continuing and incorrect-report reactions. Original English capture.

Photographs help explain conditions such as an unlit screen or damaged equipment that prose may leave unclear. They are optional: some problems are difficult to photograph, and one image cannot establish their cause or full extent. Text and images together provide context for later visitors’ judgments.

flowchart TD
    accTitle: Linking a report to a game
    accDescr: The server verifies the installed entry belongs to the arcade, then saves the report and link together.
    A["Arcade and game entry request"] --> B
    B["Verify entry ownership"] --> C
    C["Save report and game link together"]

Account votes and time-based closure rules

A vote is an account-linked response to a report. Fixed, still broken and incorrect-report responses retain who checked what and when. An account cannot duplicate its fixed or incorrect-report vote, and another still-broken response requires a 24-hour wait. This limits repeated clicks from inflating the evidence.

For ordinary accounts, resolution uses the later of the report time and the latest still-broken response. A report younger than seven days requires three fixed votes; from seven through thirty days it requires two; after thirty days it requires one. Only fixed votes from the reference time onward count, so a fresh continuing report cannot be settled using older fixed votes. Two incorrect-report votes also close it, while ninety days without a response triggers stale-report cleanup.

One vote can therefore meet the threshold on an older report, but a click is no longer an unconditional status change. The server evaluates the rules after responses and during scheduled processing. In May, we also added an exception that immediately applies fixed or incorrect-report responses from tagged accounts.

flowchart TD
    accTitle: Recording votes and deciding closure
    accDescr: Record account responses to a game-linked report, then evaluate votes and elapsed time to keep it unresolved or close it.
    A["Game-specific report and evidence"] --> B["Save account-linked votes"]
    B --> C["Evaluate votes and elapsed time"]
    C --> D["Keep unresolved or close"]

Follow-up checks in the game view and remaining work

Expanding a game shows impact, author, date, description and photographs together with other visitors’ checks. Authors describe the issue; visitors add whether it is fixed, continuing or incorrect. Readers can follow the subsequent observations with the same game rather than seeing only the initial description.

Fault details and follow-up checks appear with the same game. This screen was refined in May. Original English interface with Korean report text.

Voting still cannot guarantee conditions on site. Cleanup after a long period without responses does not confirm a repair, and account judgments can be mistaken. Keeping the game and responses together does, however, make status changes reviewable. A judgment once entrusted to one click can now be examined through several observations and time-based rules.

References: Report and voting API, Historical vote decision rules, Photo attachments, May exception for tagged accounts.

Related updates

• Musecat³ April 12th - 5th Update