Show group familiarity and apply the previous-tester admission setting #67

Open
opened 2026-11-01 20:12:33 +00:00 by viacheslavshuka · 0 comments

Organizers need to identify returning testers without pretending that group history establishes exact knowledge of current individual questions. Deliver relevant history views and an admission policy based on recorded group familiarity.

Acceptance criteria

  • Show recorded familiarity for selected blocks, distinguishing whole-block and partial-block records and their sources.
  • Every test has Allow previous testers, off by default. When off, a new application is unavailable if recorded history fully covers every selected block.
  • An unpartitioned package uses its whole-material history for the same admission rule. It does not require an artificial child block or question records.
  • Missing history does not establish full familiarity. Recorded partial attendance in an unpartitioned package does not prevent a new application.
  • Turning the setting on allows those testers to apply under ordinary automatic or manual approval. Explain that this is a group-history policy.
  • Familiarity with only some selected blocks, or partial attendance within a block, does not trigger additional approval, automatic removal, or a special review state.
  • If a confirmed tester later sees the same blocks elsewhere, preserve the existing booking. Do not request approval again or send a special notification.
  • Warn a tester applying for groups already selected in another future booking. Allow the application under ordinary rules and distinguish planned participation from familiarity.
  • Do not disclose private details of another test to unrelated organizers through that warning.
  • Do not claim exact question counts from group sizes. Authors handle individual questions moved between groups.
  • Complete history is private to the tester, with moderator access when handling a report. Organizers see their own test records and familiarity relevant to their selected groups.
  • History remains stable through normal group revisions, reordering, and mirrors. Recorded partial attendance never silently becomes whole-block familiarity.

Validation

Use explicit examples for all blocks familiar, one unfamiliar block, and one partially attended block. Change composition and verify historical selections. Test new versus existing bookings, multiple attendance sources, and cross-test privacy. Exercise the setting and warnings in the browser and API.

For unpartitioned material, test absent history, full familiarity, and partial attendance with Allow previous testers both off and on. An empty child-block list must not imply full familiarity.

Dependencies

Organizers need to identify returning testers without pretending that group history establishes exact knowledge of current individual questions. Deliver relevant history views and an admission policy based on recorded group familiarity. ## Acceptance criteria - Show recorded familiarity for selected blocks, distinguishing whole-block and partial-block records and their sources. - Every test has Allow previous testers, off by default. When off, a new application is unavailable if recorded history fully covers every selected block. - An unpartitioned package uses its whole-material history for the same admission rule. It does not require an artificial child block or question records. - Missing history does not establish full familiarity. Recorded partial attendance in an unpartitioned package does not prevent a new application. - Turning the setting on allows those testers to apply under ordinary automatic or manual approval. Explain that this is a group-history policy. - Familiarity with only some selected blocks, or partial attendance within a block, does not trigger additional approval, automatic removal, or a special review state. - If a confirmed tester later sees the same blocks elsewhere, preserve the existing booking. Do not request approval again or send a special notification. - Warn a tester applying for groups already selected in another future booking. Allow the application under ordinary rules and distinguish planned participation from familiarity. - Do not disclose private details of another test to unrelated organizers through that warning. - Do not claim exact question counts from group sizes. Authors handle individual questions moved between groups. - Complete history is private to the tester, with moderator access when handling a report. Organizers see their own test records and familiarity relevant to their selected groups. - History remains stable through normal group revisions, reordering, and mirrors. Recorded partial attendance never silently becomes whole-block familiarity. ## Validation Use explicit examples for all blocks familiar, one unfamiliar block, and one partially attended block. Change composition and verify historical selections. Test new versus existing bookings, multiple attendance sources, and cross-test privacy. Exercise the setting and warnings in the browser and API. For unpartitioned material, test absent history, full familiarity, and partial attendance with Allow previous testers both off and on. An empty child-block list must not imply full familiarity. ## Dependencies - [#35: Create and reuse author blocks, rounds, and packages](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/35). Provides stable selected groups. - [#52: Register individual testers with approval, tentative status, and capacity checks](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/52). Provides applications and existing confirmed bookings. - [#65: Correct attendance and group familiarity without erasing history](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/65). Provides corrected participation and familiarity sources. ## Related work - [#68: Generate alphabetical tester acknowledgment lists](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/68) - [#48: Give operator-appointed moderators a private report queue](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/48) - [#57: Preserve bookings and prevent stale overwrites when test details change](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/57) - [#73: Record a tester's own familiarity from testing outside Quorum](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/73)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
viacheslavshuka/quorum#67
No description provided.