A project like Basie is bound to encounter obstacles, and we were always ready to discuss all of the issues that rise throughout our work on this software. Some of the problems we will present have already been listed in other articles while some are the latest issues we encountered.
It’s important to realize that complexity of the Basie makes it hard to remove all obstacles and create a final product that won’t have any downsides. There is a high chance that new issues will pop-up even when we repair all things that are wrong with this project. But we will address those problems when they arrive.
The obstacles of the first version of Basie
Now, these are just some of the barriers we encountered after the initial build of the Basie. Some of these persisted until the present day while others were repaired. This isn’t a complete list as it would be too long if we listed all issues that plague a complex system like the Basie
1. The RSS feed for the ticket app is broken.
2. The wiki’s RSS feed points to the ticket’s RSS feed.
3. Doing a ‘diff’ on a directory in the repository browser blows up.
4. We aren’t self-hosting (i.e., we’re not using Basie ourselves on a regular basis).
5. We didn’t have a “sandbox” that’s torn down and refreshed periodically.
6. The script to import mail messages runs very, very slowly.
7. Setup on Mac is harder than it should be.
9. Tickets take a suspiciously long time to display
10. Sizing and layout need work all over the place
How to begin to address Basie obstacles
Every obstacle in the development of any project, including Basie, needs to be addressed as an individual issue. The solution for one obstacle will remove it, but it might cause other problems. This complex nature of the barriers that plague Basie makes it impossible to work on it without help. Collaboration between individuals and companies as well as communication throughout the whole process is crucial as it leads to solutions that won’t create new obstacles and mess up with the work of different parties. So communication is a key, and we have some rules that ensure successful removal of existing barriers.
1. Everyone will read these reports before our online Tuesday meeting so that we can spend our time discussing technical issues.
2. Everyone will put something—even if it’s minimal—onto ReviewBoard each week.
3. We’ll refresh the sandbox instance weekly
4. For the next four weeks, we will work toward getting Version 0.6 into a usable, releasable state.
5. Everyone will then get to spend the second half of the term working on whatever appeals to them most.