Threshold logic for ranking rounds is undefined -- advance_round silently raises NotImplementedResponse

[ayushshukla1807]

Problem

In advance_round (admin_endpoints.py), the function explicitly rejects ranking rounds:

if rnd.vote_method not in ("rating", "yesno"):
    raise NotImplementedResponse()  # see docstring above

The docstring acknowledges cases 3 and 4 (advancing from a ranking round) are unimplemented.

Separately, in get_round_results_preview, the ranking round path contains:

# TODO: What should this return for ranking rounds?
# import pdb;pdb.set_trace()

This means:

1. Any coordinator who tries to advance from a ranking round gets a generic NotImplementedResponse with no guidance.
2. There is no documented spec for what threshold semantics should mean for ranking rounds.

Impact

Campaigns that end with a ranking round (the standard flow) cannot be advanced further programmatically. While the current flow is yesno -> rating -> ranking (final), edge cases like re-running or multi-stage ranking are completely blocked.

Suggested Action

This should be triaged and either:

• Documented explicitly as out-of-scope
• Or specced and tracked as a feature

before the next major Wikimedia campaign season.

[Sanika123-art]

While testing the ranking round flow, advancement could not be reached due to an active round constraint in the campaign. This currently prevents reaching the advance_round path where ranking round handling and threshold logic (as described in this issue) would be evaluated.

Once the active round is closed, we should be able to validate the intended behavior for ranking rounds. At present, the threshold semantics and post-ranking advancement behavior remain undefined as noted in the issue.

[ayushshukla1807]

Great observation @Sanika123-art. The "active round" constraint is a core safety mechanism in the CoordinatorDAO to prevent split-brain states where multiple rounds are open in the same campaign simultaneously.

Regarding the NotImplementedResponse, the architectural challenge is that while "threshold" is a normalized score (0.0 to 1.0) in rating rounds, it doesn't have a direct equivalent in the current ranking implementation.

A potential path forward would be to redefine the threshold parameter for ranking rounds to represent a top-N cutoff (e.g., advancing the top 20 entries). I'd be interested to hear if the maintainers have a preferred semantic here before we start drafting an implementation.

[Sanika123-art]

Thanks @ayushshukla1807, that makes sense.

I’ll explore the top-N cutoff approach for ranking rounds and check how it would integrate with the existing threshold flow in advance_round.

I’ll update the PR once I have a working draft or if any edge cases come up.

[Sanika123-art]

While testing the ranking round flow further, I encountered an additional issue in advance_round.

The function attempts to call:

coord_dao.get_round_results(round_id)

but this method is not implemented in CoordinatorDAO, resulting in:

AttributeError: 'CoordinatorDAO' object has no attribute 'get_round_results'

This indicates that even if ranking round advancement is enabled, the current implementation would fail due to the absence of a corresponding DAO method for retrieving ranking results.

It appears that the ranking flow assumes a results abstraction similar to rating rounds, but this is not yet defined at the DAO level.

I’ll continue exploring a Top-N cutoff approach and how a get_round_results-like method could be structured to support ranking rounds within the existing flow.