imath
Replace Role with Capabilities
I'm not sure that custom roles are appropriate for this use case, since users can only be assigned a single role. (Technically, users can be assigned multiple roles programatically, but the Core UI only allows for one.)
That could be a problem for many organizing teams, where a person might be an Author and also a Rater, for example.
I wonder if it'd be simpler to just remove the custom roles, and use capabilities instead. In many cases, the caps might map cleanly to Core roles. e.g., I think it's common practice to give all of the organizers at least an Editor role, so it might make sense to give all Editors most capabilities by default. That would take some of the burden off of admins, since they'd no longer have to assign roles.
It might get tricky, though, because there'll be cases where someone is an Administrator (because they're in charge of maintaining the website), but also should be a Blind Rater (because they're not a member of the speaker team).
cc @andreamiddleton for insight on common organizing team practices
Your last paragraph made me add custom roles :) I'm fine with using capabilities, we just need to define the map. For instance: Editor => Juror Author => rater Contributor => blind rater
I believe part of the logic behind custom roles are cases we've seen where people outside of the organization are invited to partcipate in the voting process. So as to distinguish "guests" from "organizers". But agreed ultimately redundant. I don't think we should get caught up on every possible combination, but seek a general logic and promote best practices. Orginally, we had an option (checkbox) for creating an anonymous vote, independant of user roles. We could swing back around to this possibility after some real world feedback.
So I feel like we've answered this question for now. Do we agree that we can use existing user roles? Eventually giving some people outside the org team temporary access for voting purposes? Maybe a stretch goal could be extended roles or caps to restrict access for certain individuals to only interacting with this post type, or via the front-end (because ideally, jurers/raters do not need to access the admin).