Basie Blog

Just before Christmas, I put up a post discussing possible goals for the term. It’s time to make those more concrete, if only so that people know what they’re going to be graded on. Our high-level goals are:

1. Have fun and learn lots.
2. Impress people (at PyCon 2010 in Feb February and afterward) so that they’ll use Basie and/or help us develop it. This means having something that’s actually really truly useful and usable Real Soon.

Unfortunately, there’s tension between #1 and #2. We didn’t get Version 0.6 out the door last term (more about that below). That must be our first task this term, which means the first order of business is going to be finding and fixing bugs, tidying up Basie’s visual appearance, improving its performance, making sure that we hide things instead of erasing them, and so on. This isn’t as exhilarating as writing entirely new components from scratch, but on the upside, it’s a great way to learn how the existing code works.

Just to get us started, here’s a list of the things I believe need work:

1. The RSS feed for the ticket app is broken.
2. The wiki’s RSS feed points to the ticket’s RSS feed.
3. The titles for the mailing list and event RSS feeds aren’t in English.
4. Doing a ‘diff’ on a directory in the repository browser blows up.
5. No one has managed to get Basie running on Windows (which means some developers who might help us won’t).
6. We aren’t self-hosting (i.e., we’re not using Basie ourselves on a regular basis).
7. We don’t have a “sandbox” that’s torn down and refreshed periodically. (For people who haven’t run into the term before, a sandbox is a place where children play; in web terms, it’s an instance of an application that people can mess around in without doing any real damage.)
8. The script to import mail messages runs very, very slowly (which probably means there’s a performance problem somewhere that will bite us in Basie itself).
9. Setup on Mac is harder than it should be.
10. Our HTML, CSS, and JavaScript are inconsistent (see Chris Van Wiemeersch’s detailed email message and follow-ups from Jeff Balogh and Antoni Aloy—which, by the way, would make a blog post and/or additions to the style guide).
11. Tickets take a suspiciously long time to display (possibly because lots of unneeded data is being formatted, then hidden?).
12. We don’t have a short screencast demonstrating what Basie is, or how to set it up.
13. Sizing and layout need work all over the place (I sometimes feel like I’m looking at the “large print” edition—which, given my age, is probably not a bad thing).
14. The REST API has fallen behind the application itself, and needs documenting with lots of examples.
15. The tool Ian Lienert wrote to import projects from DrProject has fallen out of date, and we haven’t even started one to import data from Trac.
16. Basie is slow compared to Trac or DrProject (though this might reflect the server the current sandbox is on, rather than the app itself).
17. Channel management in IRC is hard enough that it might be simpler to run our own IRC server (or switch to Jabber/XMPP, or…).
18. Managing permissions and tagging (and other things that cut across components) has become so complicated that some polymorphism might be in order.

I’m sure there are more—if current or former team members want to add items as comments to this post, it would be welcome.

Now comes the hard part: figuring out what went wrong last time so that we don’t make those mistakes again. In this case, the blame for not getting Version 0.6 out last term lies squarely with me. As the project manager, it’s my responsibility to make sure (a) that developers are working on things that actually matter, (b) that their goals are realistic, and (c) that they’re making progress. I think I did a pretty good job of (a), but I fell down on (b) and (c). Some time in late October, I should have scaled down what we were trying to do, since finishing 100% of a small job is better than finishing 75% of a large one. I should also have been much stricter in the last three or four weeks about tracking who had finished what, and who was waiting on whom so that we didn’t suddenly “discover” at the end of term that we weren’t going to have a screencast because the sandbox hadn’t been refreshed because a couple of patches were waiting for review because they’d been held up waiting for answers to questions that—but you get the picture.

So here’s what I propose we do this term:

1. Every member of the team will post a punchline status report to this blog before they go to sleep on Monday. This post (from the MarkUs team) shows you what we’re after: Status, Next Steps, and Roadblocks, with bullet points for each.
2. Everyone will read these reports before our online Tuesday meeting so that we can spend our time discussing technical issues.
3. Everyone will put something—even if it’s very small—onto ReviewBoard each week, and do at least one review. This ought to mean a minimum of half a dozen small commits per week.
4. We’ll refresh the sandbox instance weekly (I’ll talk to Zuzel and Dan about the best schedule) so that we can always see what state the code is in.
5. For the next four weeks, we will work toward getting Version 0.6 into a usable, releasable state.
6. Everyone will then get to spend the second half of the term working on whatever appeals to them most.

Please let me know what you think—as with almost everything else in this course, it’s negotiable, but PyCon is our big chance to make a good impression on the world, and I think this plan gives us the best shot at making the most of it.