Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

If we only expect FeedbackFromTeams on the orallist, multiple submissions should unconfirmed each other #473

Closed
philipbelesky opened this issue Jul 4, 2017 · 3 comments
Assignees

Comments

@philipbelesky
Copy link
Member

philipbelesky commented Jul 4, 2017

I assume it is a relatively rare issue that a team would (through malice, or incompetence) submit on all of their panellists and also the chair. However if we expect feedback only on the oralist, whenever a submission comes through for an adjudicator from a team it should probably unconfirm their previous feedbacks for adjs on that same panel.

This both removes those 'bad' pieces of feedback from the feedback scores, but also ensures that the team record pages and expected feedback pages will give a better guide of what is actually going on.

@czlee
Copy link
Member

czlee commented Jul 4, 2017

I see, so if they submit on the (not-rolled) chair and then a panellist, only the latter is confirmed causing it to look like there's no submission on the chair and an unexpected submission on the panellist? (This is the effect it would have.)

@philipbelesky
Copy link
Member Author

Yea, that's exactly the result I'd like. The thinking here is that it would hopefully solve two problems at once: the need to 'clean' unexpected feedback from the database and signal to teams that they are doing something wrong. Even if they don't realise what they are doing wrong, hopefully the tracking page at least prompts them to resubmit feedback on the chair one more time and in doing so unconfirmed their previous attempts.

@czlee
Copy link
Member

czlee commented Jul 5, 2017

Cool. This actually interferes with the current mechanism a little; we might have to implement it at a different layer. Will think on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants