WUDC Algo: Export/Import JSON file

[chief-nerd]

Exporting the DRAW structure into a JSON File so @czlee can process it. Also allow the JSON structure to be inputted via REQUEST

[chief-nerd]

@czlee I created the basic export to work for you. Have a look at the wiki file: https://github.com/JakobReiter/tabbie2/wiki/DRAW-Export-Format

[czlee]

Thanks! I probably should have put this up on this thread straight after the meeting, here's the info I'd like to have. Things that I think are in the current export format are checked, things that I can't find are not:

• Adjudicators, and their
  • [x] Names (for display)
  • [x] Institutions
  • [x] Rankings
  • [x] Gender(s)
  • [x] Region(s) (see remark 3)
  • [x] Language status(es)
• Teams, and their
  • [x] Names (for display)
  • [x] Institutions
  • [x] Gender(?)
  • [x] Region (see remark 3)
  • [x] Language status
• The draw
  • [x] Teams that are in the debate
  • [x] How many points the room is on (this can be associated with teams instead)
• [x] Teams that adjudicators have seen, and in which rounds (see remark 1)
• [x] Judges that adjudicators have paneled with, and in which rounds
• [x] Teams that adjudicators conflict with, ~~and to what degrees~~ (see remark 2)
• [x] Judges that adjudicators conflict with, ~~and to what degrees~~

So basically: can we add names, gender, regions, language statuses, and indicate which round past teams/adjudicators were in?

Remarks:

1. Current format specifies past adjudicators and teams, but doesn't specify when. We want to take it into account for the first time in this system. I appreciate that this might be a bit of work, how much would it be? (The actual work is not urgent, I just want to see if it can be done.)
2. I think "degrees of conflict" aren't currently specified in Tabbie2 (or any tab system); they're a nice-to-have. Consider this low priority, since we don't even have a precise idea of what this means yet, and it's much more likely that we will treat all conflicts as hard.
3. As always, I'm not fussy about how the information is structured, just what information is present. So for all of region, gender and language status, I don't mind whether these are provided in a separate list, or whether they are added to the existing arrays representing each adjudicator/team (or something else). Similarly, regions need not necessarily be associated directly with adjudicators and teams, for example, it's fine if a separate list of institution-region mappings is given instead.

By the way, Adjumo will ignore Tabbie2's adjudicator allocations completely; it's starting from scratch. So I'll just collate all the adjudicators (under data[i]["panel"]["adjudicators"] for each i) into a single list in Adjumo. This isn't a problem, I just thought I'd mention it in case some other solution is easier for Tabbie2.

[chief-nerd]

@czlee I added everything I could do so far. You will have to work with what is there now. Everything else will quite be difficult to add - so I hope this works for you.

Remarks 1: actually quite some work, since this is quite a join to figure out. I have unfortunately currently not the time to alter AND (way more important) TEST those alterations

Remarks 2: Treat all them as hard - because that's what they are

Remarks 3: You find all the const definition in their model files unter /common/models/ Let me know if there is something missing.

Please be sure to return the DRAW in the same structure, so it will be easy for me to parse it back in.

[czlee]

We can't really do anything useful (at all!) without access gender, language and regions. It's not necessary for this information to be incorporated into the same structure, or even the same file: a dump of all adjudicator and team info for the tournament in a separate array downloaded from a different location, or locations, will work just fine. It needn't even be related to the draw. The same goes for round history—I could just parse through all previous draws myself if that's what it takes. I'm happy to download as many files as we need to, parse as much redundant information as you like, and return a file that conforms to your specified structure. I'm hoping at some level the export should just be some sort of selective dump?

Actually, thinking out loud—if you can guarantee that team, speaker and adjudicator ID numbers will stay consistent throughout the entire tournament (as primary keys typically do), and if we assume names, genders, languages and regions don't change from round to round, Adjumo could import names, genders, languages and regions directly from registration information at the beginning of the tournament. This isn't a perfect assumption in practice, so we'd need to keep the two databases in sync manually, e.g. when a correction is made, or when the language committee releases their final decisions.

But this still requires us to know which IDs refer to which teams/adjudicators, so we'd still need some initial export from Tabbie2 somehow.

Thoughts? Can we add Chris to this discussion?

[chief-nerd]

Hey you got access to gender, language and region in this version! So you can DO stuff with it :) The ONLY thing missing is the history component. If they are so freaking important to you I will make them tomorrow (if I have time)

[czlee]

Oh sorry, my mistake! I missed the commit you added.

Detailed history is not so important if it's difficult. Firstly, we can retain this information from previous rounds in Adjumo if we need to. Secondly, if you can do this even as late as early December, it's a small enough change for me to handle later anyway. If you're pressed right now then I wouldn't sink any more time into it. Thanks for making time to do this this weekend!

[czlee]

Correct me if I missed something again, but what's your take on

• Speaker gender (or "team gender", which is just an aggregation of speaker genders that Adjumo can do)
• Team region
• Adjudicator language status (I know this isn't formally defined in the same way as it is for speakers but adj core wants to take it into account with allocations, we should ask Chris if you need details on how this would be set)

No need for immediate implementation, just an agreement on the output format. The implementation can come at the beginning of December and I'll be happy; it's just that a common format now would allow me to start implementing the core work now :smiley:

[chief-nerd]

Team Gender .... well that is rather hard. The current commit has a gender for every speaker. You can aggregate that to whatever level you need to. I would think that male, female, mixed would do, but then again transgender and not revealing should also be taken into account.

Region: as you might have seen the decade stands for the continent and the single digit for the UN Sub region. I also think that will suffice in regards of detail. last instance you still have the country itself.

Adjudicators (technically) also have a language status, since this field belongs to the user behind the role. So I you want I could give you a language status. BUT (and this is a big one) the language officers would ALSO have to set the adjudicators language status (which would be possible) BUT A LOT OF WORK FOR THEM!

Let me know ... MAYBE I can do 1h or so tomorrow. (or Monday since that is the Austrian Independence Day - ergo a bank holiday)

[chief-nerd]

@czlee and before I forget: you could also do the changes yourself ;) Feel free to commit and push :)

[czlee]

I would if I knew PHP! I'd at least want you to vet them first. Maybe I'll try them on a different branch some day and run them by you :wink:

I was getting confused with reading through all the commits, sorry. Everything looks good. On team gender, Adjumo can (and should) do the aggregations itself.

On language status—I think what you have in mind sounds great but you raise an excellent point, we should discuss this with Chris to see what they have in mind.