Naturally, a lot of my input on this will relate to how the Quizbowl Resource Database fits into this technology platform. The database was designed with a similar goal in mind of unifying as much as possible into a single system; a lot of the functionality suggested thus far are things that I've long wanted to implement in the database or see implemented elsewhere. Of course, when I'm the only one who's really ever worked on the database, my full time job is in software development, and I spend so much time traveling to tournaments and taking a break from programming/quizbowl, it's no surprise I haven't devoted nearly as much time to it as I have wanted. (Too bad all the free time I had in high school/college was spent on sloppily-coded MSHSAA-style quizbowl influenced VB.NET/Access web apps that are now defunct...) As much as I've wanted to implement some of this stuff myself, it's obvious that I simply don't have the time for it, and it makes more sense for the qualified community as a whole to collaborate on a unified quizbowl software ecosystem.
The Quizbowl Resource Database was written almost entirely from scratch by me in PHP, using MySQL, with basically no frontend/backend libraries whatsoever other than what php (and phpBB) provide. Anyone joining the effort to maintain that would have to deal with PHP, the strange things I've come up with, etc. The most obvious benefit of the current system is that it is tightly integrated with the forums - it uses phpBB credentials to authenticate users so people who have a forum account don't have to maintain a separate account to use it, and it also allows us to generate those (hopefully not too annoying) emails asking people to post tournaments to the database when they announce them on the forums. It is also extremely convenient to have tournament listings, statistics reports, and question sets all in one place, and it would be nice to add on more functionality to that centralized system.
As much as I'd hate to see another one of my personal programming projects go defunct, it's becoming more apparent to me that it probably makes more sense to leverage the talents and availability of the community and come up with something new and improved rather than try to use what little time I have to maintain it myself or bring others on board and have them learn the quirks of the current system. With 4+ more years of industry experience since I first started the database, there are certainly some things I would do differently if I were to do it all over, and this community effort may be a good way to do that. I'm really glad this discussion is happening now, because with the end of the regular season in Missouri, I'm finally coming up with some free time to work on the database again, and it would be good to know if I'd be working on something that would last for a long time or if it's just going to be rendered obsolete by something else in a few months.
As for some of the features suggested in this thread:
grapesmoker wrote:Tournament management. To me, this is the currently most pressing need, driven in large part by the fact that ACF has been doing tournament management by spreadsheet, and that has required a great amount of manual work on our part. I envision a system in which teams can seamlessly register themselves for tournaments, hosts and TDs can see who is registered for what, and teams can get invoices for their registration, all in an automated fashion. Schedule construction is a feature that one would probably like to add once the above basic functionality is obtained.
I have wanted to implement this for several years now but it has never made it to the top of my task list. This functionality is a natural fit for the existing tournament database - this is the reason why pricing information on database entries is entered the way it is and not as a free-form text box, for instance. I was hoping to implement this by next fall, but then again, that's something I've said the last 2 summers. This is the kind of situation that I don't want to see fragmented across multiple systems; I would like to see this tightly integrated with the community's "master" tournament database, whether it be integrated into the existing database, or written in a way that the existing tournament database could eventually be replaced with it.
grapesmoker wrote:Scorekeeping. Right now, we do all our scorekeeping on paper, necessitating a dedicated stats person who enters the scoresheets into SQBS. Since we are no longer living in the dark ages of 2004 when you could never know whether a university would have some reasonable level of wifi access, I think it's time we thought about moving to an online scorekeeping system. I have previously linked to a skeleton of such a system, which kind of works, but obviously needs to be much more rigorously tested.
Cody wrote:As a TD, there are often times when I cannot get everyone internet access - and this is true much more often than not. While I, of course, would love to see a good online scoring system, I would also really like a good replacement for SQBS that handles things more sensibly.
Jonah wrote:One corollary to Ashvin's statement that "I think the best way to approach this at first would be to allow the online service to consume SQBS files" is that we really need a better data interchange format, preferably one that allows variation in the amount of granularity (in a perfect world, everything from buzz points to just teams' records or even just their rankings. Human readability would be a plus.
While SQBS importing would be good for importing archived statistics to the system, I think a better interchange format is a must to ensure maximum compatibility between applications. Like Cody, I definitely want to see an offline solution that integrates naturally with the system. I have never had internet access on my laptop when directing the NAQT Missouri Qualifier at Mizzou, and rarely have internet access on my laptop when doing stats at area high schools. When posting stats, I would much rather have people upload the raw data file and generate the HTML on the server side, but the obscurity of the SQBS format has pushed that extremely low on my priority list. A good interchange format would also make it much easier for people to get a raw data dump to use for their own purposes (for instance, something like HSQBRank that could pull raw data from a central database and calculate team rankings automatically). Ideally, this interchange format would support arbitrarily merging data from multiple sources as automatically as feasible (for inputting stats from multiple places, other services synchronizing data with the master database without wasting bandwidth getting redundant dumps, etc).
I would like to see a new statistics platform written from scratch that uses an extensible, well-documented data format/backend so that frontend applications could be developed for various platforms (web interface, standalone PC/Mac/etc. that could be used offline, iOS/Android/Windows Phone/etc.) and functionalities (stat viewing, SQBS data entry replacement, electronic scorekeeping, BEeS-like system, etc.), for whichever combinations of those things demand exists. It must
be designed with rebracketed tournaments in mind, so you don't have to juggle multiple data files - this is by far my least favorite thing about SQBS.
Here's an overview of my vision of how a unified system could work, which brings together some things that already exist in the current database and some other things proposed so far. (Note that anything I suggest as "automatic" should be an optional aid and the output from such "automatic" functions should be manually modifiable if necessary.)
- A master database would contain information about all the various schools, organizations, people, etc, involved in quizbowl. This database could be used to generate contact lists for hosts to send out tournament announcements, hosts to contact willing staffers in the area, etc. This should definitely be designed in a way to reduce the risk of making this contact information readily available in bulk to spammers or other nefarious people. (For instance, by limiting access to email addresses to trusted registered users, etc.)
- Tournament hosts announce their tournaments and add them to the tournament listing database, allowing people to register using an online registration form. These tournaments are linked to the question set they are hosted on.
- Teams search for tournaments in their area and register for tournaments they'd like to attend. In the ideal case that all tournaments were in the database and used the database for registration, teams could be alerted if they've already registered for a tournament on that date, on that question set, if there's a closer tournament on that question set, etc.
- Teams could also subscribe to tournament listings to be alerted when new tournaments are announced in their area.
- Tournament hosts can use the registration system to keep track of which teams are registered, how many buzzers and staffers they have, etc. Invoices could be generated and sent to teams through the system.
- Teams would enter their rosters in the online system before the tournament. For high school tournaments, the roster entry could prompt for college information, and the player database could effectively replace the existing Freshman Contact List.
- The tournament listing could display a list of registered teams and rosters.
- Before the tournament, a blank statistics data file could be generated from the entered rosters.
- The roster/team information could be passed through a system that analyzes past tournament statistics to generate a preliminary seeding.
- The system could suggest a schedule based on the number of packets and teams, user-provided scheduling constraints, etc.
- The TD can adjust the seeding as desired and then have teams placed into the schedule automatically, with an option to automatically swap teams to avoid teams from the same school being in the same pool, enhance geographic diversity, etc.
- This data file could be fed to a schedule viewer that produces a schedule suitable for printing. The schedule could also be made available online so that attendees can look up the schedule on their phones/tablets.
- Data entry could be handled multiple ways.
- It could be done online from a web interface or Internet-connected program or app, either from a central stat person or from scorekeepers in each room.
- One or more stat people could enter statistics offline in a manner similar to how SQBS works now, and these data files could be merged with each other and/or uploaded to the central database anytime.
- A BEeS/Abacus like frontend could eventually be used.
- The schedule data and entered results could be fed to a feature that evaluates the possibility of ties for rebracketing occurring based on certain outcomes in the remaining rounds.
- The statistics program could use the schedule to automatically rebracket teams based on the entered results. The schedule viewer could be used to print new schedules, or teams could just get the schedules online.
- The tournament host uploads the file to the statistics repository after the tournament (if not throughout the day), making the report available to the public and the data available to anyone interested in using the data.
- When a question set is posted after all mirrors have concluded, all teams that registered for a tournament using that set could be notified, if desired.
- As mentioned and otherwise implied earlier, the central statistics repository would have data in a format that could be easily consumed to create rankings, playing histories for schools/teams/players, etc.
Anyway, I would love to be involved in this project with whatever time I can find to do so. I don't really have any experience with the various frameworks/libraries that exist today; my web-based programming experience is just several personal projects using PHP/MySQL (older projects in VB.NET), and my professional experience technology-wise is not particularly relevant to this project.
If this project involves replacing the existing Quizbowl Resource Database with a reboot based on this new ecosystem, I'd naturally be able to help out with this transition and to make sure all the data in the existing system is migrated. I would like to see the tight integration with the hsquizbowl forums continue because of the benefits of having a single account provides, and I imagine we could figure out a way to do that even if the new system is written in something other than php. If the system ends up being completely independent of hsquizbowl, I have been sitting on quizbowl.org for over 5 years now and I think this would be a great use for that domain for whomever will be hosting this service.