Distribution Entry: UI for Category Entry

[ ] There needs to be a standard set of top-level categories (TLCs) from which you can select. There should be no manual typing of a category name unless it is not present in the system. This should take the form of a drop-down box, alphabetically sorted.
- [ ] To start, TLCs present in the system should include Literature, History, Science, Fine Arts, RMP, Geography, Current Events, Trash, and Social Science. One might even separate RMP into individual categories given the differences in how sets have been handling the category.
[ ] As now, the distribution entry screen should start with 1 line of entry; there should be a plus button between the line of entry and "Submit changes" that performs "add a new category" -- this should allow you to specify a new TLC.
[ ] Every TLC entry should have a plus button to the left of the category name that performs the function "add a subcategory"
- [ ] All of the standard TLCs should have an associated set of standard subcategories. For example, in Literature, this would be "American", "British", "European", "World".
- [ ] Pressing plus on a standard TLC automatically creates all its standard subcategories, which can be removed if so desired.
- [ ] VHSL- and NHBB-specific subcategories can be added later (since we are mostly done w/ VHSL for the year).
[ ] Instead of a "Category" box, there should be a "Manual Entry" link that turns the dropdown box into a text field, so that you can specify a custom category name. (clicking "Manual Entry" is then replaced with "Pre-configured Entry" which brings back the dropdown when clicked.)

All category entry should work pretty much the same. We shouldn't have any distinction for what we do for TLC vs. other types of categories.

On Mon, Jan 19, 2015 at 7:30 AM, Theta91 notifications@github.com wrote:

There needs to be a standard set of top-level categories (TLCs) from which you can select. There should be no manual typing of a category name unless it is not present in the system. This should take the form of a drop-down box, alphabetically sorted.

— Reply to this email directly or view it on GitHub https://github.com/grapesmoker/qems2/issues/210.

How is it going to know that we want "4/4 literature per packet irrespective of any subcategories or rounding" if there is no concept of a top-level category? If it's just adding probabilities of subcategories you could end up with almost any end product.

Also, the distro entry screen is broken now; trying to submit changes or add a row gives "All question numbers are required and are per packet" no matter what is put in the boxes.

The top level category thing is being done as part of the larger packetization work. I have most of the business logic for that written, but I'm still working on debugging it and writing tests.

For the second issue, that's a bug probably due to something new I've added to the Distribution model. I think I may have actually fixed this already but it hasn't been deployed yet.

In general, I need to think about how the transition is going to go from existing distributions to the new model. It's a fairly disruptive change at this point. In summary, don't get too attached to current distribution work.

On Sun, Jan 25, 2015 at 9:26 PM, mweiner1 notifications@github.com wrote:

How is it going to know that we want "4/4 literature per packet irrespective of any subcategories or rounding" if there is no concept of a top-level category? If it's just adding probabilities of subcategories you could end up with almost any end product.

Also, the distro entry screen is broken now; trying to submit changes or add a row gives "All question numbers are required and are per packet" no matter what is put in the boxes.

— Reply to this email directly or view it on GitHub https://github.com/grapesmoker/qems2/issues/210#issuecomment-71416149.

I just made a change to not reset.

On Sun, Jan 25, 2015 at 9:29 PM, Michael Bentley < bentley.michael.j@gmail.com> wrote:

The top level category thing is being done as part of the larger packetization work. I have most of the business logic for that written, but I'm still working on debugging it and writing tests.

For the second issue, that's a bug probably due to something new I've added to the Distribution model. I think I may have actually fixed this already but it hasn't been deployed yet.

In general, I need to think about how the transition is going to go from existing distributions to the new model. It's a fairly disruptive change at this point. In summary, don't get too attached to current distribution work.

On Sun, Jan 25, 2015 at 9:26 PM, mweiner1 notifications@github.com wrote:

How is it going to know that we want "4/4 literature per packet irrespective of any subcategories or rounding" if there is no concept of a top-level category? If it's just adding probabilities of subcategories you could end up with almost any end product.

Also, the distro entry screen is broken now; trying to submit changes or add a row gives "All question numbers are required and are per packet" no matter what is put in the boxes.

— Reply to this email directly or view it on GitHub https://github.com/grapesmoker/qems2/issues/210#issuecomment-71416149.

It still isn't possible to enter a distribution -- I'm looking to get NASAT and CHB set up.

This should be fixed now.

On Tue, Jan 27, 2015 at 5:07 PM, mweiner1 notifications@github.com wrote:

It still isn't possible to enter a distribution -- I'm looking to get NASAT and CHB set up.

— Reply to this email directly or view it on GitHub https://github.com/grapesmoker/qems2/issues/210#issuecomment-71762765.

This is not a pressing matter since no set will be expected to use in-system packetization until at least the time NSC 2015 needs to be built, but at some point when it's convenient for you, I'd like a full overview of how this is going to work, in light of the following issues raised:

How it's possible to have no concept of a top-level category and still guarantee that, e.g., every packet has exactly 4 history tossups as opposed to whatever sum of subcategories happens to land there Whether we are going to move away from the need for every creator of a distribution to manually calculate total questions needed in every subcategory as opposed to using the superior percentage-and-templating method *Whether the UI will be improved to work with what people actually want to do -- e.g., modify categories in a set that's already created, rather than forcing them to create a new distribution from scratch and be bound to it once a set is created

*How it's possible to have no concept of a top-level category and still guarantee that, e.g., every packet has exactly 4 history tossups as opposed to whatever sum of subcategories happens to land there

There are still top level categories, but they don't really work differently than lower level categories.

So when you define your distribution, you say it has 4 history tossups, 4 history bonuses, a minimum of 8 history questions per round and a max of 8 history questions per round. You similarly define there as being 2.5 European History tossups, 2.5 European History bonuses, a minimum of 5 euro history questions and a maximum of 5 euro history questions per round. The 2.5 means that it's guaranteed to pick between 2 and 3, and the minimum of 5 means it's guaranteed that it won't select 2 tossups and 2 bonuses (for a total of just 4) per round. These all end up adding up. It's a little hard to explain but I am writing various tests to guarantee that we don't run into rounding errors and other weirdness.

*Whether we are going to move away from the need for every creator of a distribution to manually calculate total questions needed in every subcategory as opposed to using the superior percentage-and-templating method

Percentages make it more complicated to calculate requirements since you can't as easily say "this is the number of tossups and total questions I want in this subcategory per round". It also means that you need a different algorithm for these top level categories than sub and subsub categories which makes things messier. It's something we can explore doing in the future if there's a huge need. I do plan on at least displaying percentages on the UI screen where you enter these things.

I don't think I know what you mean by templating.

*Whether the UI will be improved to work with what people actually want to do -- e.g., modify categories in a set that's already created, rather than forcing them to create a new distribution from scratch and be bound to it once a set is created

You will be able to modify a distribution and then re-run the set packet requirements algorithm for an existing set.

On Wed, Jan 28, 2015 at 11:05 AM, mweiner1 notifications@github.com wrote:

This is not a pressing matter since no set will be expected to use in-system packetization until at least the time NSC 2015 needs to be built, but at some point when it's convenient for you, I'd like a full overview of how this is going to work, in light of the following issues raised:

How it's possible to have no concept of a top-level category and still guarantee that, e.g., every packet has exactly 4 history tossups as opposed to whatever sum of subcategories happens to land there Whether we are going to move away from the need for every creator of a distribution to manually calculate total questions needed in every subcategory as opposed to using the superior percentage-and-templating method *Whether the UI will be improved to work with what people actually want to do -- e.g., modify categories in a set that's already created, rather than forcing them to create a new distribution from scratch and be bound to it once a set is created

— Reply to this email directly or view it on GitHub https://github.com/grapesmoker/qems2/issues/210#issuecomment-71894721.

Percentages make it more complicated to calculate requirements since you can't as easily say "this is the number of tossups and total questions I want in this subcategory per round". It also means that you need a different algorithm for these top level categories than sub and subsub categories which makes things messier. It's something we can explore doing in the future if there's a huge need. I do plan on at least displaying percentages on the UI screen where you enter these things.<<

I don't see how this is the case, because for most subcategories you don't want a per-round whole number anyway. For example, the only things that usually break down to 1/1 per round in ACF format are biology, physics, European literature, and world history. Everything else is less than 1/1 or sometimes more (if, for example, American literature is not further split, it will usually end up being either 2/1 or 1/2 per round).

What I'm saying is this: The entire process of using QEMS2 to enter the set needs right now reduces to me looking at my desired distribution, seeing that we want 30% of social science to be economics, multiplying 30% by 1 social science tossup per round by 20 rounds in a set, and coming up with 6, then repeating that for forty subcategories and manually entering it twice. There's no reason whatsoever that the program cannot do this math for me. This includes rounding if I have, say a 15-packet set and I want 25% of social science to be psychology -- it never "matters" on a significant level whether it takes the 3.75 spit out by the formula and turns it into a 3 or a 4. If it mattered that much to an editor, he will set it to come out as a whole number to begin with; otherwise, the program should just randomly round it up or down and then keep doing so to the other numbers in the subdistribution until they add up to the whole distro.

Again, this is exactly what I am doing by hand every time a set is created, so I know it's possible. The big advantage of having it done by the program is that editors can set and tinker with their actual distributions directly rather than setting up another spreadsheet to do the multiplication themselves.

Calling it a "percentage" versus a "question number" similarly doesn't matter -- for anything but the three or four subcategories, out of the forty-ish we use, that break down to exactly 1/1 per round, you already would have to enter something like 0.3 economics tossups per round or 1.32 British literature bonuses per round, for ACF format. These numbers are literally just percentages multiplied by the number of top-level questions in the category and divided by 100. They are mathematically equivalent. Entering percentages and entering questions should thus be the same thing as far as the difficulty of building the program is concerned, but percentages provide a huge advantage to the user because we can do what HSAPQ wants and use the same subdistribution across sets with different top-level distributions. We want 33% of literature to be American literature whether that's 33% of the 6 tossups and 3 one-part bonuses that literature gets in a VHSL packet or 33% of the 4 tossups and 4 three-part bonuses that literature gets in an ACF packet. The point of doing it this way is to enable making policy changes without having to manually recalculate everything -- certainly the program is capable of reading from the master HSAPQ subdistribution and doing the trivial arithmetic necessary to convert percentages into numbers of questions, rather than making a person do this every time.

By templating, I mean that the process should work as follows: The top-level format/distribution and the group subdistribution are imported. The multiplication and rounding performed above is done. The program builds "packets" that just say 1. AMERICAN LITERATURE TOSSUP, 2. CHEMISTRY TOSSUP, etc., including building the desired number of tiebreakers which also can read directly from the top-level/percentages math (eliminating that whole complication). The displayed needs are based on summing up what's actually in the packets.

The main advantage here is that by essentially building the packets before the questions are in, it's impossible to end up with a mismatch between what's written to the calculated needs at time N and what comes up when following the packet-building rules at time N + 1. In the entire five-year process of using QEMS1, this was the only way we found to accomplish that task. A secondary benefit is that editors have the entire writing period to look for problems in the packet templates and make swaps to fix them -- if, for example, we never figure out how to specify "the packets with a social science tossup always have a current events bonus" (or any arbitrary example that's more complex, as I hope that sort of thing will be solved) then it's much better to let the editor go in and manually move questions around to meet the desired end product ahead of time rather than making it impossible to do that task until the packets are built and we're getting closer to the deadline.

What I'm saying is this: The entire process of using QEMS2 to enter the set needs right now reduces to me looking at my desired distribution, seeing that we want 30% of social science to be economics, multiplying 30% by 1 social science tossup per round by 20 rounds in a set, and coming up with 6, then repeating that for forty subcategories and manually entering it twice. There's no reason whatsoever that the program cannot do this math for me. This includes rounding if I have, say a 15-packet set and I want 25% of social science to be psychology -- it never "matters" on a significant level whether it takes the 3.75 spit out by the formula and turns it into a 3 or a 4. If it mattered that much to an editor, he will set it to come out as a whole number to begin with; otherwise, the program should just randomly round it up or down and then keep doing so to the other numbers in the subdistribution until they add up to the whole distro.

You will not need to enter these manually. The program will calculate it for you. You tell it you want 4/4 history and how many rounds you have and it figures out the top level history requirements and the subcategory requirements. If you're using the same distribution from one set to another there will be pretty much no work apart from selecting your distribution.

Calling it a "percentage" versus a "question number" similarly doesn't matter -- for anything but the three or four subcategories, out of the forty-ish we use, that break down to exactly 1/1 per round, you already would have to enter something like 0.3 economics tossups per round or 1.32 British literature bonuses per round, for ACF format. These numbers are literally just percentages multiplied by the number of top-level questions in the category and divided by 100. They are mathematically equivalent. Entering percentages and entering questions should thus be the same thing as far as the difficulty of building the program is concerned, but percentages provide a huge advantage to the user because we can do what HSAPQ wants and use the same subdistribution across sets with different top-level distributions. We want 33% of literature to be American literature whether that's 33% of the 6 tossups and 3 one-part bonuses that literature gets in a VHSL packet or 33% of t he 4 tossups and 4 three-part bonuses that literature gets in an ACF packet. The point of doing it this way is to enable making policy changes without having to manually recalculate everything -- certainly the program is capable of reading from the master HSAPQ subdistribution and doing the trivial arithmetic necessary to convert percentages into numbers of questions, rather than making a person do this every time.

I'll see what I can do to make this easier for people entering sets but it's low on my priority list. Having the absolute numbers for total questions (and min/max) makes it easier to know for certain that the packetization is working correctly. I'm sure someone else could probably figure out a different way to do this that meets your needs.

By templating, I mean that the process should work as follows:

It should work more or less like that, but I wasn't planning on having Step 3 take place until you actually finish the set. Otherwise you need to do one of two things. The first option is the program auto-generates a bunch of placeholder questions. To complete the set you'd edit these questions. But that means that everyone needs editing permissions and makes it a bit hard to deal with things like "this question got moved from the set" or "this question was moved from history to geography". I already support creating these questions, I just planned on it being something that happens when the set's like 95% complete. The other option I guess is that you create a completely different set of objects for these placeholder questions and use that to guide where questions randomly go in later. I suppose this could be created but it would add complexity and it's not something I'm planning on doing right now.

On Wed, Jan 28, 2015 at 9:01 PM, mweiner1 notifications@github.com wrote:

Percentages make it more complicated to calculate requirements since you can't as easily say "this is the number of tossups and total questions I want in this subcategory per round". It also means that you need a different algorithm for these top level categories than sub and subsub categories which makes things messier. It's something we can explore doing in the future if there's a huge need. I do plan on at least displaying percentages on the UI screen where you enter these things.<<

I don't see how this is the case, because for most subcategories you don't want a per-round whole number anyway. For example, the only things that usually break down to 1/1 per round in ACF format are biology, physics, European literature, and world history. Everything else is less than 1/1 or sometimes more (if, for example, American literature is not further split, it will usually end up being either 2/1 or 1/2 per round).

What I'm saying is this: The entire process of using QEMS2 to enter the set needs right now reduces to me looking at my desired distribution, seeing that we want 30% of social science to be economics, multiplying 30% by 1 social science tossup per round by 20 rounds in a set, and coming up with 6, then repeating that for forty subcategories and manually entering it twice. There's no reason whatsoever that the program cannot do this math for me. This includes rounding if I have, say a 15-packet set and I want 25% of social science to be psychology -- it never "matters" on a significant level whether it takes the 3.75 spit out by the formula and turns it into a 3 or a 4. If it mattered that much to an editor, he will set it to come out as a whole number to begin with; otherwise, the program should just randomly round it up or down and then keep doing so to the other numbers in the subdistribution until they add up to the whole distro.

Again, this is exactly what I am doing by hand every time a set is created, so I know it's possible. The big advantage of having it done by the program is that editors can set and tinker with their actual distributions directly rather than setting up another spreadsheet to do the multiplication themselves.

Calling it a "percentage" versus a "question number" similarly doesn't matter -- for anything but the three or four subcategories, out of the forty-ish we use, that break down to exactly 1/1 per round, you already would have to enter something like 0.3 economics tossups per round or 1.32 British literature bonuses per round, for ACF format. These numbers are literally just percentages multiplied by the number of top-level questions in the category and divided by 100. They are mathematically equivalent. Entering percentages and entering questions should thus be the same thing as far as the difficulty of building the program is concerned, but percentages provide a huge advantage to the user because we can do what HSAPQ wants and use the same subdistribution across sets with different top-level distributions. We want 33% of literature to be American literature whether that's 33% of the 6 tossups and 3 one-part bonuses that literature gets in a VHSL packet or 33% of t he 4 tossups and 4 three-part bonuses that literature gets in an ACF packet. The point of doing it this way is to enable making policy changes without having to manually recalculate everything -- certainly the program is capable of reading from the master HSAPQ subdistribution and doing the trivial arithmetic necessary to convert percentages into numbers of questions, rather than making a person do this every time.

By templating, I mean that the process should work as follows: The top-level format/distribution and the group subdistribution are imported. The multiplication and rounding performed above is done. *The program builds "packets" that just say 1. AMERICAN LITERATURE TOSSUP,

CHEMISTRY TOSSUP, etc., including building the desired number of tiebreakers which also can read directly from the top-level/percentages math (eliminating that whole complication). *The displayed needs are based on summing up what's actually in the packets.

The main advantage here is that by essentially building the packets before the questions are in, it's impossible to end up with a mismatch between what's written to the calculated needs at time N and what comes up when following the packet-building rules at time N + 1. In the entire five-year process of using QEMS1, this was the only way we found to accomplish that task. A secondary benefit is that editors have the entire writing period to look for problems in the packet templates and make swaps to fix them -- if, for example, we never figure out how to specify "the packets with a social science tossup always have a current events bonus" (or any arbitrary example that's more complex, as I hope that sort of thing will be solved) then it's much better to let the editor go in and manually move questions around to meet the desired end product ahead of time rather than making it impossible to do that task until the packets are built and we're getting closer to the deadline.

— Reply to this email directly or view it on GitHub https://github.com/grapesmoker/qems2/issues/210#issuecomment-71969621.

grapesmoker / qems2

Distribution Entry: UI for Category Entry #210