We've got a problem and would like a less hackish way to fix it. Help!

Problem:

We're a coalition of teams in Boston dedicated to various aspects of and we only have one active deployment at the Cambridge Friends School which, in this case, is coordinated by a Harvard-based loop team called One For All; the loop team serves as the contact point between the school and all these independent teams of volunteers.

But we digress. We've got a lot of things To Work On, and they're floating around in a Nebulously Undefined Cloud that occasionally emits noises that sound a lot like "we have stuff to do, but we're not really sure what stuff needs to be worked on now." Most of our volunteers are busy students or working people who don't have the bandwidth to constantly keep up on what's going on. Every time they cleared a block of time (intermittently available, not-necessarily-at-regular-planned-intervals) to volunteer, they had to go through a huge overhead of asking around and finding out what needed to be worked on, where to get the resources to do it, who they had to give what to by when, how they would know when they were done...

If only there was a way they could, at any given moment, look at an open list of well-defined to-do items with deadlines, explanations of the milestones they're working towards, and all of the resources and contact information someone would need to pick up the job and do it...

Our current hack:

A few of us got fed up with this one afternoon, sat down and made a wiki status page with some tasks, and started driving a schedule of more regular check-ins (schedule still stabilizing, but getting there).

There are obvious scaleability problems with this. Beyond this pilot, beyond these short-term deadlines, we have no way to track our to-do list without going insane. Even now, managing the page by editing it is a pain. Watchlisting the entire page for email updates (so we won't forget) sends us a message any time any task is changed, not just the ones we care about.

Is there a better way?

This sounds like a job for a ticket tracker. We set up a temporary Trac instance on Colin's shared server account and are moving towards that for our second temporary solution - I say "temporary" because it's a pain in the neck to set up and maintain, and takes time away from what we want to focus on (serving the technical needs of local deployments).

What we'd really like is to have a ticketing instance hosted elsewhere, administered by Someone Else. We don't really care who. We don't even really care what platform it is (RT, bugzilla, Trac... whatever), as long as it's for deployment tickets rather than code bug-tracking. We'll have tickets like "install the Maze Activity on all of Mrs. Johnson's class's laptops" - not a bug but a to-do item- as opposed to "Maze feature such-and-such is broken, please fix" (which we'll file upstream in the appropriate development bugtracker if we find it). Deployment tickets, not development tickets.

This would make a great community-group service for Sugar Labs, olpcfriends, or a similar group to offer for deployment groups - a set of conditions (who's eligible, what maintenance you must provide, what terms of usage you have to agree to) for getting Trac hosting with certain features and services provided, and a handy subdomain (deployments.sugarlabs.org?) for access. This shouldn't seem like such a strange idea; Sugar Labs already does it for code hosting.

O Metabrain, what can we do?