Convert public submission forms to be by Person

[tienne-B]

Currently the public adjudicator feedback form is broken due to it taking a Team object. When giving everyone a private URL key #690, the public (non-private key) forms were broken by this new object.

Please see:
#684 (comment)
#684 (comment)
#684 (comment)
For previous discussion on the topic.

Possible solutions are to get make_feedback_form_class() to re-accept Team objects or replace teams in the list of forms to their constituant speakers.

[czlee]

Hmm, if lots of people use the public submission forms, I don't think we can deprecate them. There's administrative overhead in managing private URLs, and it'll be worth it for some tournaments but not others. It's not a dealbreaker for me if the log consequentially lacks this information, unless there's some functionality wouldn't make any sense without knowing which speaker was behind the submission.

[tienne-B]

Not the right task @czlee; will write that "issue" to discuss soon. This one is purely about this bug Adjudicator or Team (this task assumes that we are keeping public submission forms)

[czlee]

For what it's worth, all of these issues seem very closely related to me, and I'd rather have the discussion in a single thread. I agree #684 was the wrong place for it, but I don't really see how we can discuss #707 and #709 separately.

[tienne-B]

Understood; and it would be okay to bring both discussions here (feel free to close #709). However, I feel that a broken part of a feature should be fixed, regardless of whether there is also discussion on whether to remove/deprecate the whole feature. In that sense, this task could be closed during that discussion, as a resolution to this is not necessarily a resolution for #709, and there are different approaches that could be done for this bug. Anyways, feel free to "merge" both into one; I was just separating the task somewhat arbitrarily.

[czlee]

Okay, so here are four options, which in the long run I believe are mutually exclusive, in that only one of them can be part of the software at any given time:

(1) Make public forms by speaker, in that the URL references their speaker ID, not their team ID
(2) Keep public forms by team, but add a field that has them select which speaker they are
(3) Keep public forms by team, and don't log which speaker submitted it
(4) Deprecate public forms

I don't think (4) is an option for the reason @philipbelesky gave over at #684 (comment); they're used quite often, and I can see why people would (as I said above).

(1) would require the submission index to list speakers rather than teams, making the list twice or more as long; (2) would add a field to the submission form. These aren't drastically time-consuming additions, but in my experience most adjudication teams don't care which speaker submitted feedback—and if the tournament is small or informal enough for public submissions to be enabled, they especially wouldn't care. So I think most participants would, rightly, see this as an unnecessary and bothersome step.

That leaves (3). Is it bad if we don't log which speaker submitted it? To answer this—why do we log things? In my mind it's just to allow after-the-fact detective work, say, to allow tab directors to understand what happened when a submission looks wayward (or, in a different context, to allow them to figure out how an adjudicator unexpectedly ended up in a particular room). With private URLs, it's useful information to know whose private URL was used, because then you know either that person submitted it or the private URL was compromised (and knowing whose was compromised might help teammates piece together how that came to be). With public submissions, I'm not really sure what we learn beyond "it was a public submission [from this IP address]", given that there's no concept of a public URL being "compromised".

But more generally, we normally log things on a "best effort" basis. Logging isn't central to an application, so things should never break merely because logging couldn't work. So if the only reason to add functionality that affects user workflow is to keep logs happy, to me that's not a reason at all.

[philipbelesky]

Yea, I'd be in favour of (3) rather than guessing at a speaker or reworking the interface for public ballots. At the point the interface is public and anonymous a log doesn't really provide much real information as CZ mentioned.