Closed kmeesters closed 9 years ago
Not sure what you want with the behavior of those ronds in a stage. I thought each round now only had a number. Should it be possible to reorder rounds? (what the mock data suggests)
Well assinging a number is fine, but that means we have to check for duplicates, and make sure al other places present the rounds according to the number. We can scratch the ordering in that case (or the ordering is a way to change the numbers)
I think Jeroen means that the number of rounds is actually a property of a stage. That's how $stages currently implements it. It then automatically creates an array like [1, 2, 3] in the stage's $rounds property. Reordering stages could be nice though.
On 3 november 2014 22:40:51 CET, Kenny meesters notifications@github.com wrote:
Well assinging a number is fine, but that means we have to check for duplicates, and make sure al other places present the rounds according to the number. We can scratch the ordering in that case (or the ordering is a way to change the numbers)
Reply to this email directly or view it on GitHub: https://github.com/FirstLegoLeague/fllscoring/issues/59#issuecomment-61553754
Allright. To clarify: there might be a difference between the ID and the order (often the 'name') of the rounds. For example if they are not created in the right order. So you should be able to move them around. This can be implemented through the sorting buttions or just a modifiable text field with some contraints (no duplicates)
They might be created in a different order then shown here, hence the option to sort (or assign a place) manually). However sorting is of less importance for the first deliverable. Creating and selecting one of the 3 rounds is however :-)
In the current implementation, the semi final would be a stage, with one round, and the final another stage, also with one round. I think this is the way it should be, as the number of teams that participate in these two stages differs. But you could also have finals with 2 rounds of course.
On 3 november 2014 22:53:28 CET, Kenny meesters notifications@github.com wrote:
Allright. To clarify: there might be a difference between the ID and the order (often the 'name') of the rounds. For example if they are not created in the right order. So you should be able to move them around. This can be implemented through the sorting buttions or just a modifiable text field with some contraints (no duplicates)
- 1: Practice Rounds -- 1: Round 1
- 2: Qualification Rounds (always 3) -- 1: Round 1 -- 2: Round 2 -- 3: Round 3
- 3: Finales -- 1: Semi final -- 2: Final
Reply to this email directly or view it on GitHub: https://github.com/FirstLegoLeague/fllscoring/issues/59#issuecomment-61556043
Yup, I agree, bad example, but you the point is the numbering of rounds in a stage
I'm still not convinced of the purpose of rounds reordering. Mostly, they just have a numer which is also their name (i.e. round 1, rond 2, etc), I think it would just confuse the crap out of people if it is even possible that round 2 is not the second round. (Reminds me of Felienne's scoring system for dancing compititions where rond 1 is actually the second one, since she started couting at 0). If rounds always have a consecutive ID and you are able to rename them, there is no need for the more complicated reshuffle GUI/backend. It will also reduce the risks of admins actually doing this, which would be very confusing. (I do see the need to be able to change the tournament structure while the tournament is running though. this can later be enhanced by restricting this to rounds or stages where no scores are submitted to)
@kmeesters Can you give an example of how the numbering of rounds in a stage could be different from 1, 2, 3?
Note that there can also be stages without any rounds ('unused stages', i.e. myStage.rounds = 0, such that myStage.$rounds = []), which are NOT available in $stages.stages, only in $stages.allStages. @Jheronymus I think it's better to use $stages.allStages in the settings control.
Additionally, there can be stages that have only one round (such as most finals, but you could organise a final with more than one round). In that case, the GUI of e.g. Ranking is already 'optimised' in that it doesn't show "Highest" and "Round 1" columns, but simply one "Score" column.
Likewise, the Round selector on the Scoresheet could be ommitted if a Stage with only one round is selected.
Currently, I don't see the point in being able to 'rename' rounds, but if there is a real use case for it, it would help if we know it soon, as rounds are used in many little places throughout the code.
Hmm apparently a comment from has 'disappeared' form this thread. I'll try to rewrite. A round should always have a number (integer). And then a name. The name could also be composed of stage + round nr. For example: Practice Round(s) 1
However you need to ensure that the round number are always consecutive and unique. The specific implementation does not matter to me (whether a text field or reordering buttons).
Furthermore the only thing I can imagine (now) is the semi finals where the 1st ranked team plays the 4th. And 2nd vs. 3rd. So the names would become:
Finally I think with each round you should be able:
Combining stage name + round number is easily achieved, also with the existing implementation. Even having these 'separate' Semi Finals is currently possible, if they are entered as separate stages (you would either have one stage "Semi Final" with 4 teams playing in it, or two stages having 2 teams each then).
Renaming and re-ordering is already possible, but only for the stages. Deleting a round is also possible, but only 'highest' rounds (i.e. first the last, then next-to-last, etc., you cannot delete only round 1 of a multi-round stage).
However, your use-case of moving a round to another stage is interesting: that's not really possible at the moment, at least it would require updating the stage and round property of all affected Score entries.
If we're going in this direction, we can better turn the whole stages concept around: there will mainly be a list of rounds, and each round has a property that 'points' to a stage. Currently, all scores have a 'stageId' property (e.g. "qualifying"), and a 'round' property (a number). In the 'new' scenario each score would have only a 'roundId' instead (which should be a unique primary-key-like thingy).
Not sure whether it's worth the trouble though. Maybe indeed changing the stage and round properties of each score isn't such a bad thing to do when 're-purposing' a round (like in your example), because that's in fact what's happening, and it won't happen very often.
I'd like to keep it like it is for next weekend :) Maybe we should discuss the pro's and con's on one of the next meetings.
Discussed with @Jheronymus Conclusion:
For stage and rounds creation:
A STAGE has the following properties:
A ROUND has the following properties:
In display (like scoring form and ranking screen)
We omit the the delete and move functions for now, will create a separate issue for another milestone.
Nah, there are some issues with that proposal (such as that the $stages service should not know about scores, in my opinion, that's better handled by $scores, like current $scores.scoreboard), that a round now doesn't have any relation to a stage, and that there's no unique key that can be used in e.g. a score entry to refer to the round.
As just discussed with @Jheronymus, there's no need to do this at all right now (as we can put sensible defaults in the code and/or edit the data/stages.json
file by hand for next weekend).
So I guess my remark about discussing this in more detail during a follow-up meeting still stands :)
Dumb question: Am i missing this file in the repository?
And yes: you just need to attend the next meeting :)
That file is not in the repository, it's created when $stages.save() is called, like the teams.json file, the scoresheets, etc.
If the file's not there yet, some default stages are loaded instead.
Okay, follow up dumb question: where are defaults defined? (destroying all my credits from the last night here)
Hehe, I believe you still have some credits left ;)
You'll find the details here: https://github.com/FirstLegoLeague/fllscoring/blob/a8c9a187b088f0e48284b397001517e5719faafd/src/js/services/ng-stages.js#L70
For pragmatic purposes (time), sticking to the current implementation:
Implemented like this:
You can add stages, move them, edit them and delete them. Also added a wee bit material design, which will flow through the rest of the app.
An interfaace has been created in the settings see commit https://github.com/FirstLegoLeague/fllscoring/commit/07a5cf50bf3fe995f09c580f14b1e32ecf296f93
Martin has written the backend code (#42) someone needs to hook-up the frontend to the backend :)