The basic requirements are: (1) let challenge participants declare whom they're working with, this group being visible, and (2) impose submission quotas that apply to a participant even when someone else on their team is the one creating the submission in Synapse. This presentation elaborates on the basic requirements:
Design Approach
1) A Challenge is a Project with some extra metadata. Implement this as a new object which a Project can 'own', and on which CRUD operations can be done independently from the Project.
2) Introduce new Team-Challenge association to let participants associate their Team with a Challenge.
3) Explicitly limit the number of Submissions per 'round' ('phase'?) of a Challenge on a per-user basis. A Submission has a list of associated _users_ which is 'initialized' in the UI (prior to being submitted) to be the membership of a Team MINUS unregistered Team members MINUS Team members who exceeded their submission limit. The client submits a _finalized_ participant list as part of the Submission.
4) Users are notified of submissions with which they are associated and may opt out. (This prevents another user from consuming one's submission quota). Opting out must occur prior to scoring.
User Experience
Challenge administration:
- make a new Project
- make Evaluation queues, setting start/end of rounds and max submissions per participant per round
- set Challenge attributes: (1) registration Team, (2) Evaluation queue list, (3)
User registration:
User submission:
unchecked-disabled Team member: "This member has exceeded their submission quota. You may ask them to 'opt out' of pending submission(s) by other Team(s) they are on, then retry this submission."
Opt out:
- user receives submission notification email.
- user following link in email to Portal.
- Portal list submissions for which user may opt out.
Response to User Protests:
* I should have been included in that submission because I'm on the Team that submitted.
* I wasn't able to submit, but I had yet submitted so I wasn't over quota.
Objects:
Challenge
- id
- registrationTeam
- evaluations
Evaluation
- start-of-first-round-timestamp
- <end-of-round-timestamp-list>
- maxSubmissionPerRound
Submission
- EligibleSumitters
- <Team Members> (list of principalIds. this is the "truth" about who are the submitters)
instead of EligibleSubmitters we can add
- TeamId
- Team Name
EligibleSubmitters
- TeamID
- Team Name
- <principalId, isRegistered, exceedsQuota, isEligible>
- timestamp
- EvaluationId
SubmissionOptOut
- SubmissionId
- principalId
- createdOn
- createdBy (redundant with 'principalId?')
ChallengeTeam
- challengeId
- teamId
- message (e.g. for recruitment)
Note: 'contentSource' is redundant for Challenges, but not for non-Challenge projects. How do we handle this? Maybe add evaluation list to Project, not Challenge.
Services
- Submission bundle includes opt-out list, Eligible Submitters (in addition to Submission and SubmissionStatus)
- Note: It's worth exposing the Challenge ID, not 'hiding it' in the Project. This is so we can relate it to EligibleSubmitters and to tell if a Project is also a Challenge.
| URI | Method | Request Body | Response Body | Authorization |
|---|---|---|---|---|
| /entity/{id}/challenge | POST | Challenge | Challenge | CREATE permission required in parent project |
| /entity/{id}/challenge | GET | -- | Challenge | READ permission required in parent project |
| /entity/{id}/challenge | PUT | Challenge | -- | UPDATE permission required in parent project |
| /entity/{id}/challenge | DELETE | -- | -- | DELETE permission required in parent project |