Show group familiarity and apply the previous-tester admission setting #67
Labels
No labels
area/backend
area/frontend
area/tooling
kind
build
kind
chore
kind
ci
kind
docs
kind
feat
kind
perf
kind
test
size
l
size
m
size
s
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Blocks
Depends on
#70 Let testers manage their participation through Telegram buttons
viacheslavshuka/quorum
#73 Record a tester's own familiarity from testing outside Quorum
viacheslavshuka/quorum
#35 Create and reuse author blocks, rounds, and packages
viacheslavshuka/quorum
#52 Register individual testers with approval, tentative status, and capacity checks
viacheslavshuka/quorum
#65 Correct attendance and group familiarity without erasing history
viacheslavshuka/quorum
Reference
viacheslavshuka/quorum#67
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
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
Related work