Proposal for Enhancements to the Project

[timiil]

Dear Maintainer,

I am excited about the potential of our project and would like to propose several enhancements to improve its functionality and user experience. Below are my suggestions:

1. Add a 'Referee(group)' Entity: This would allow us to assign referees to each match.
2. Match Calendar: Implement a feature to schedule matches on specific dates, in addition to setting times.
3. Add 'MatchID' Property to 'Match' Entity: This addition would enable listing all matches in a table and facilitate the export/import of tournament data in formats like XLS/CSV.
4. Enhanced Statistical Information for 'Match' Entity: Storing detailed match statistics such as yellow cards, red cards, and suspensions in a JSON format could be beneficial.
5. Detailed Match Results: For sports like snooker, tennis, or table tennis, recording detailed scores (minor scores) could enhance the depth of match results.
6. Expanded Match Results: Introduce more nuanced results such as 'A seized by referee', 'B seized by referee', and 'A and B seized by referee', along with a 'ResultMemo' property for special notes.
7. Tournament States: Define states such as [Draft], [Running], and [Archived] to manage the tournament lifecycle more effectively. In the [Draft] state, all data can be modified without entering match results. Once in the [Running] state, only match results should be updatable. Finally, the [Archived] state would freeze all data, allowing only queries.

I am confident in contributing to the back-end (DAL/BLL) updates required for these features. However, I am less familiar with the React-based frontend and would appreciate any support or collaboration on that front.

I look forward to your feedback and hope to contribute effectively to the project's success.

Best regards

[evroon]

Thanks for sharing your thoughts!

1. Add a 'Referee(group)' Entity

This would be useful indeed, but not something I plan to work on, contributions would be appreciated though.

• Match Calendar: Implement a feature to schedule matches on specific dates, in addition to setting times.

• Add 'MatchID' Property to 'Match' Entity: This addition would enable listing all matches in a table and facilitate the export/import of tournament data in formats like XLS/CSV.

These are more frontend issues, start times of matches are already saved in a timestamp format, it's just easier to forget about the date part. Matches already have a primary key ID, though we could also add a column for string-based human readable IDs.

Enhanced Statistical Information for 'Match' Entity: Storing detailed match statistics such as yellow cards, red cards, and suspensions in a JSON format could be beneficial.

That's quite a big feature and still a bit vague to me, I don't want Bracket to be tied to specific sports where you use red cards for exameple, so it would have to be more generic/abstract.

Detailed Match Results: For sports like snooker, tennis, or table tennis, recording detailed scores (minor scores) could enhance the depth of match results.

I'm not sure what that entails.

Expanded Match Results: Introduce more nuanced results such as 'A seized by referee', 'B seized by referee', and 'A and B seized by referee', along with a 'ResultMemo' property for special notes.

That might be too much of a feature-creep for now, and I'm not sure what problem it would solve.

Tournament States: Define states such as [Draft], [Running], and [Archived] to manage the tournament lifecycle more effectively. In the [Draft] state, all data can be modified without entering match results. Once in the [Running] state, only match results should be updatable. Finally, the [Archived] state would freeze all data, allowing only queries.

Interesting idea, I like the idea of archiving tournaments and making them read-only. In running state, more should be able to be updated IMO. Bracket should be flexible enough (and already is) to handle changes to team setups or changing team names etc. during tournaments, which is an important feature that other tools don't have.

[evroon]

I added #690
I have turned it into a discussion, if you have more actionable ideas, please create an issue for them.