Ongoing work on the Basie project

We have been working on our Basie project for several years, and the improvements we have achieved are evident. We corrected mistakes that plagued us for years, and we improved a rather simple forge into something that can rival already existing forge software. But we want more.
We don’t want to develop forge software that rivals competition, but software that will exceed them. This means that we have to work harder on our project and come up with solutions that will turn average forge software into something that will surpass the expectations.

Goals we reached in development of the Basie

We achieved a lot with Basie, and that includes milestones and improved dashboard. We tackled issues that were deemed impossible and found solutions that satisfied various tests. We solved problems that others didn’t even think about and that turned our software into a superior forge. We came up with some solutions, and these two are just the most important ones we tacked and prevailed.
1. Milestones:
MilestoneThe purpose of a benchmark is to group a set of tickets. Bug fixes tend to be somewhat stand-alone, but tickets that are related to a new feature tend to come in logical groups. By creating an entity that can collect groups of tickets, display a “target date,” and quickly report on % completion, we feel that we can add definite structure to our ticketing system.
2. Improved Dashboard:
The dashboard is a widely used concept. It’s meant to give a quick snapshot of recent progress and a real sense of future direction. Our panel currently takes a pretty ‘direct’ approach. We have a big chronological list of what has been happening across the platform, and a few charts that try and add visual cues.
Issues we have to solve
We already mentioned that we are far from the final product we have in mind. Basie still needs more features that would make it highly-versatile software we envisioned. These two following ideas are just the tip of the iceberg of ideas we plan to implement in the future.
1. Attachments:
The argument for attachments is mostly based on anecdotal evidence of a problem. Students spend the entire term sending back and forth emails containing attachments, which can later be hard to find and don’t show up in the archives of a project for future developers. The proposal is that we create attachments directly on our tickets, as well as wiki pages.
2. Improved Diff Engine:
Deep in Basie’s guts, we have what we refer to as an “audit trail.” It’s a versioning system that tracks every change made to every object in the system. Our source browser hooks directly into a version control system (SVN for now), so there’s similar functionality there. The question is: how do we display differences between the objects?