Future Project Ideas

[mmcinnestaylor]

DOMjudge Server

• DOMjudge version update (8.2.x)
  • v8 utilizes a different input file format, therefore the input file generator Celery task located in src/contestadmin/tasks: generate_contest_files will require updates.
  • Requires update to Chapter's DOMjudge deployment files
• DOMjudge I/O file size limit [complete]
• C# update and associated .NET version
  • Update judgehost image (Docker hub acmfsu/judgehost)

Registration Server

Support Libraries

• The django-hashid-field library has been retired. This library is used to hash the fsu_num attribute of the Profile model since the raw value can be tied to student financial information. Updating the project to work with an active library would improve maintainability long term.

Framework

• Update Django to next LTS version (5.2.x)
  • Yet to be released as of 2024/09/01
• Enable/implement Django sitemap generation

Styling

• Update Bootstrap to 5.x
• The site could use a visual overhaul. This would be an opportunity to change CSS frameworks if a more fundamental change is sought. A good project v2.0.0 milestone.

Project-wide

• Persistence across contests
  • The current implementation assumes that there is only one Contest object in the database. The consequence of this is that the database must be wiped before each contest, as users and course information is not associated with a particular contest. In order to provide longevity (creating one account and registering for multiple contests over time) an entire over haul of the system would be required. A good project v2.0.0 milestone.
• Refactor function based views to class based views

utils

• GUI for course and faculty input file creation tools (currently uses comand line input)

django-admin

• The Django Admin interface is currently restricted to users with the superuser privilege. It would be useful to consider updating the permissions to allow organizers who aren't superusers to access the interface.
  • Django docs: Permissions and Authorization
    • Granting a user staff status will allow them to access the admin site, but additional permissions must be granted to allow them to edit any of the database models
  • Use case: posting/updating contest announcements

Miscellaneous

• Contest image gallery/archive
• Dedicated volunteers section/page for posting updates, information, etc

announcements

• Volunteer announcements
  • Announcements delivered exclusively to users who have a role other that Contestant.
• Pin announcements feature
  • Display pinned announcements above standard announcements.
  • This can be on the admin side, where important announcements are listed above others. This could also be on the user side, where announcements a person wants to pin can impact their individual announcement listings.
• The display and navigation of the full announcements list can use a cleanup
  • The back button in the individual announcement view always navigates back to the announcement list, even if a user navigated to the announcement from elsewhere on the site (ex. from the homepage by clicking 'Read More') [complete]

checkin

• The entire check-in flow can use a visual overhaul
  • Better form display/styling
• A group check-in feature may be useful, particularly if a room assignment feature is to be added.

contestadmin

• Admin password reset [complete]
• Admin account deactivate
  • Deactivating an account prevents anyone from logging in as that user.
  • Use case: a contestant creates two accounts. This often happens when they forget their username/password or register with a bad/unreachable email address. Ideally, the unused/duplicate account should be deactivated, and the contestant uses the primary account.
• Automated room assignments
  • A routine to automatically assign a team to a specific room, and possibly even specific seats in a room, in order to maximize the efficient use of seating space during a contest.
  • This would require new database models, updates to existing models, and some background with algorithms. This is a lot like a bipartite matching problem. Processing assignments the night before (offline matching) is easier to solve but also risks wasting a lot of assignments on teams which don't show up. Processing assignments during check-in on contest day (online matching) is even more difficult though from an algorithmic perspective.
  • Add graphs/visuals to the contest statistics view
    • Mermaid Diagramming and Charting Tool
  • Add ability to export contest stats
  • Allow faculty members to use an email other than @cs.fsu.edu
    • The current implementation assumes the username portion of the address (the part before the @) is unique. This assumption is utilized in several places:
      1. In src/contestadmin/tasks.py: generate_ec_reports each CSV filename uses the format username_course-code.csv
      2. In src/contestadmin/tasks.py: email_faculty the username portion of the email address is used to find relevant EC reports.
      3. In src/contestadmin/urls.py the URLs generated for each faculty member's dashboard use an encoded version of the username portion of the email address.
      4. In src/contestadmin/views.py: FacultyDasboard the username portion of the email is used both in the get and download methods.
    • Using a different method of uniquely identifying faculty members would allow them to use any valid email address of their choosing.

core

• Homepage
  • Add faculty first name initial to courses display
  • Improve sponsor logo section
    • The three current sponsor logos are hardcoded into the template.
    • An updated display could allow the most prominent sponsors to be displayed on the homepage, and have a secondary Sponsors page which displays all contest sponsors.
    • Ideally, sponsor logos could be uploaded semesterly. A Sponsor DB model with an image, sponsor name, website, etc would make a good foundation for Sponsor information page.
• Teams page
  • filter teams display by checked in status
• FAQ
  • Add search/filter tools to display subset of relevant questions
  • A chatbot which serves FAQ information would be very useful.

lfg

• Long story short, this module was written before Discord transitioned to a new username format. This update as well as updates to the Python package used to enable Discord support, discord-py, have broken this module. The idea behind LFG was to assist people who are in need of teammates to find each other. This was initially designed to use the Chapter's Discord server, but it could be redesigned to use something more web/Django centric, such as a matching/filtering and messaging systems, or live chat systems.
  • I think moving away from the Discord integration is more sustainable in the long term.
  • Using something like django-postman would enable messaging between users without needed to leave the registration server platform.

manager

• The profile dashboard and many of the submenus can use a visual overhaul and updated styling
• Participation certificate generator
  • Contestants have asked for some sort of certificate or official acknowledgement of participation and/or their team's results. This could be something like generating a PDF certificate from a template which has relevant team information and/or contestant information included.
• Add faculty first name initial to course display (dashboard and select courses views)
• Reassignment of team admin role
• Freeze editing team name and deleting a team after after generate_contest_files runs (ie after the DOMjudge contest files are created)
• Once team registration deadline passes (Contest.registration_deadline), update the Team card to show new team creation is unavailable

register

• The entire registration flow can use a visual overhaul
  • Better form display/styling
• User register as volunteer
  • Currently, volunteer status must be assigned by a Contest Organizer using the update tool on the Contest Dashboard. Adding some sort of automated authentication process for a user to register an account as a confirmed volunteer (has a passphrase, PIN, etc?)
• User confirm registration info before account creation
  • A procedure to confirm an email address is reachable before it is used to register an account. Basically, send a confirmation code.
• Add search/filter function to team list when joining a team
• Restrict use of medal emoji in team names (the emoji is used to denote top 3 finishers in contest)
• Group registration
  • May not be worth the time, but allowing multiple people to submit a signup request at once
  • Some code exists in the module's views.py but is not included in the project
• Support multiple schools
  • Use case: In the past, high school teams have participated in the contest. DOMjudge supports the display of more than one Institution(schools, etc).
  • Would likely need to build a school model, where a team selects a school assignment during creation/management.
  • Would require updating the input file generator Celery task located in src/contestadmin/tasks: generate_contest_files