Friday, July 31, 2009

Wrapping up for the summer

I just spoke to Steve about plans for wrapping up our projects for the summer, and he asked me to write up a summary of the steps we'll need to take before the fall.

  1. Prepare for the poster session

  2. Make screencasts
    We're planning on releasing demos as screencasts for each project. Maybe we should make a quick and dirty one right away to get feedback and throw light on those features that need work before the end of the summer, and then make a nicer one in a few weeks?

  3. Move the source to a public site such as sourceforge
    If we do this right away, we can ticket code cleanup tasks to give us a nice roadmap for the end of the summer, and for any future development on the projects.

  4. Provide documentation
    Make sure code is commented nicely and provide an overview for future developers.
    Also include help/about/how-to information in the app, where appropriate, for end users.
    We can also do light refactoring and clean up code as we comment.

  5. Fix bugs and remove hacks
    It's easy to leave in buggy features in a single developer project if you know the workaround. We'll need to fix that up. A better testing suite would be nice to have, but might be of lower priority than fixing the bugs we know we have.

  6. Add one or two killer features
    We'll need to brutally triage so we don't ignore the boring but necessary cleanup and documentation tasks, but we got great feedback this week from people who watched our presentations and we've all got a couple of features we'll want to be able to leave the project with


By way of example, here's how I think we could apply this to our project, TracSNAP.

  1. Prepare for the poster session
    The screenshots and explanation on the poster could be reused as documentation and info for the front page of our TracHacks page.

  2. Make screencasts
    I already have an idea of what I want fixed for our screencast from the demo session we just did. A quick one soon would be good, though.

  3. Move the source to a public site such as sourceforge
    TracSNAP belongs on TracHacks. I'll throw our source up there and start ticketing changes as soon as I get the go-ahead from Ainsley.

  4. Provide documentation
    I can go through the code and check for any egregious omissions in commenting this weekend. On Tuesday, I'll add barebones user-accessible help on each feature. We'll put together an overview of features for the poster session and our TracHacks plugin page next week. Beyond that, I think maybe better documentation should wait until we've fixed a few bugs and decided on what features we'd like to add by the end of the summer..

  5. Fix bugs and remove hacks
    We have several known bugs and ugly workarounds in our project, and moving to a real project management system and ticketing them is the first step. Then we'll prioritize and work on fixing them.
    Most pressing: Update repository data on every commit. Remove extra tabs only used for development. Grab real emails and work on mapping Trac logins to subversion logins in a sane, if not perfect, way. Decide on saner algorithms for determining relatedness and expertise.

  6. Add one or two killer features
    Since JSViz seems to be pretty broken for parent nodes with >18 children, moving to Flare is probably a key feature. This is Ainsley's department and I'll defer to her judgement on whether it'll be doable in less than a month. Jon Pipitone suggested we get together with Brent and a few grad students and work together on a code sprint to get Flare up and running on both TracSNAP and Breadcrumbs, if possible.
    Other possible features:
    • Improved UI - request suggestions, and make everything scale better with screen size.

    • Import social network data from existing products that generate it from email logs and the like.

    • Adapt Anita Sarma's algorithms from the Tesseract project for determining relatedness to this project.

    • Do you have a suggestion? Leave a comment - thanks!