Provide support for Retro-Hugos

[arkoebel]

Dublin's going to have Retro Hugos and we need some ways to support that.

The easiest way would be to simply double the number of categories, but it might be confusing for the voters and administrators to have that many categories in the same list.

From a users POV, it would be better to provide a super-category (Award?) and allow the web page to display the categories coming from the same super-category. Then we could put both either on the same page or in separate pages depending on the design wishes of the administrator.

[djm4]

Given the time-frame, would it be acceptable to have a single list of categories during the nomination phase, and look at having something richer for the voting phase?

[eemeli]

Given the divergence between the Dublin and upstream code branches, an important factor here is figuring out if and when you'll want to transition to a rebased solution for your instance. Upstream is getting much more modular, allowing for easier customisation.

Regarding the specific implementation, there are three aspects to consider:

• The back-end: Probably easiest to just double the categories so you'd have both Novel and RetroNovel, rather than double the whole instances.
• The nominator front-end: Probably easiest to have two nominating pages, each with their appropriate categories and accompanying text.
• The administrator front-end: Not sure tbh. Having separate pages might be a bit clumsier, but it'd avoid the (nominal) possibility of mis-correcting an entry between the retro & non-retro categories.

[djm4]

Thanks! I agree completely about the codebase divergence; that's a much bigger conversation, but this one certainly needs to be informed by it.

Looking at the schema, I don't think it would be a lot of work for all the Hugo tables to acquire a Ballot or similarly-named field, with values Hugos and Retro Hugos or similar. Then we could get proper separation between the entries without relying on category naming. We'd need an extra table for category-to-ballot mapping, I think, but again, that should be doable.

[arkoebel]

Regarding the divergence of versions: the idea was to migrate to the dublin branch here on maailme, but since the infamous #60 it's a bit harder to keep track of changes in the master.

My idea short term is not to touch the API (unless David thinks it's better in the long term: it might require changing the unique key in the database), 2 nomination/vote links and everything on the same page for admins.