Set up a Trac-based project-management system for Tor

We're trying to move to a project-management system to organize our work. We want our system:

  • To reflect work at a level somewhat more coarse-grained than tasks
  • To track deliverables that we've promised to org/sponsors, and relate them to our products
  • To reflect other things we need to enumerate more.

We've made a start of it at the wiki:projects page, but there's more work to do. We should at least:

  • Finish this TODO list; make sure there's nothing missing.
  • Write up a good description of our project-management system at org/process/HowWeDoProjectManagement.
    • Start writing the page
    • Describe the workflow better
    • Describe how to indicate the type of a project
  • Write a good template for what should go on a project page.
  • Identify other projects to add
    • From contracts
    • From TODO files
      • TODO.external
      • TODO.future (about 25% done. Some of it should be a BlueSkyDesignIdeas wiki page or something)
      • TODO.02* (mostly done; some remaining stuff is just echoes of proposals.)
    • Proposals
  • Add some hierarchy to the org/projects namespace? Instead of projects/ProjectName, let's have projects/ShortProduct/ProjectName.
  • Add links to external TODO lists that won't be maintained with this system.
  • Make sure that all current official deliverables are entered.
  • Figure out what to do with the existing projects/Product pages for org/roadmaps/BridgeDB, org/roadmaps/TorCheck, etc. Most of these are just lists of TODO items, partially converted to trac entries. We could make an arbitrary project for each TODO item, or we could try to group them up into projects, or such. When grouping tasks into projects, we might call that project "release version x.y of product z" so that we have a goal to work on.

karsten: I'm moving these pages to org/roadmaps/*. These pages describe what the status of a product is and how we want it to be in the future. Whenever we start working on an item we should start a project or a task. When we're done we should update the roadmap.

We also have some questions we need to answer, including:

  • Figure out a threshold for deciding what's a project. Can anybody add one? Tor devs only? What distinguishes blue-sky projects from active projects, etc?

andrew: tor-devs, but we need some sort of approval system. Assume 100% of dev time needs to be allocated to projects (and preferably to a sponsor).

nickm: Let's say, anybody can add a "project idea" as future/blue-sky and approval is only needed to make it an active, worked-upon project.

  • Must every to-item of every project have a trac ticket, or only certain ones?

andrew: I suggest yes. if you're going to spend time on a task, it needs to be tracked with a ticket.

nickm: I don't like this, but I'll start trying to do it and see how awful it is. I think the issue here is that my to-do items tend to be more fluid and fine-grained for lots of stuff.

  • Where might there be other lists of projects that we're forgetting?

andrew: there should be none.

  • What is the threshold between "being a project" and "being a task" ?

andrew: tasks are atomic bits of more than 4 hours but less than 3 weeks of constant work. A project/milestone is a large-scale task with a definite endpoint, such as a software release, a site launch, or a report delivered. A milestone consists of multiple tickets and can display a rough graph of progress based on the proportion of tickets completed.

  • Is every project closed-scope, or are there open-scope projects?

andrew: projects by definition need to have a definite endpoint. I'd like projects to be no more than 6 months long.

  • If not every last to-do entry is a trac ticket, how do we extract reporty things for funders?

andrew: a mix of milestone progress bars and human work to convert tasks and projects/milestones into pretty reports for human consumption.

  • Consider reporting project progress via some other system than trac's milestones. The number of closed tickets is an ugly metric for project progress, especially when we expect others to evaluate our progress without looking at the details.

andrew: the goal of trac is lightweight metrics about progress. the project owners and andrew should always know where anything stands.

nickm: It seems from the phone conversation that funders are okay with getting stuff explained to them, and it's okay to keep the tasks on any given milestone up-to-date, even if doing so makes the %-done part of a milestone fluctuate rather than increasing monotonically.

karsten: Here are a few things that I changed or plan to change:

  • We represent active projects by tickets and prefix them with "Project: ". A better way might be to add a fourth ticket type "project" (in addition to defect, enhancement, and task) and use that for project tickets. This makes it easier to search for either projects or tasks.

nickm: Adding a new "project" ticket type seems like a great idea, if we can actually distinguish projects from nonprojects. I bet we can.

karsten: Yes, we can search by ticket type.

  • We shouldn't maintain a manual list of active projects in the wiki like the current one on org/projects. Nobody wants to update such a list which is why the current page isn't very useful. We should rather let Trac generate a list of all tickets starting with "Project: " (or of all tickets of type project). See the Projects section on org for how such a list of active projects would look like.

nickm: I'm agreed about letting the list of projects be autogenerated.

  • If we need to create a wiki page for a really complex project, we should make sure that it disappears once the project is over. Projects are temporary things and so are the project wiki pages. We shouldn't accumulate work plans for completed projects in the wiki. My suggestion would be to copy the wiki page to a text file and attach it to the project ticket when closing it. If it wasn't just a work plan but something we want to keep, it needs to go somewhere else (code repository, tor-dev mailing list, proposal directory, etc.) anyway.

nickm: I'm against deleting wiki pages unless we archive them somewhere, but if we archive them somewhere that's fine. I agree that distinguishing active from inactive stuff is important.

karsten: It's probably a case-by-case thing. If we needed a wiki page only to agree on child tickets and their order, we can very likely dump it when the project is over. If the wiki page turned into a design document it should go somewhere else. If the wiki page is relevant for sponsors to see how the project went we should turn it into a final project report and send it to them. When in doubt, we should archive the wiki page in the project ticket.

  • I renamed the product pages in org/projects/* to org/roadmaps/* for two reasons. First, I wanted to avoid the ongoing confusion between projects and products. The remaining pages in org/projects/* are for projects, the pages in org/roadmaps/* are for products. Second, we need to continuously update the product roadmaps to reflect where a product is, but we don't care about a project page once the project is over (and therefore should delete it as described above). So, blue-sky projects and projects that aren't ready for action should now go to org/roadmaps or one of the subpages.

nickm: I'm fine with the renaming, but I'm not completely sure what the roadmap pages are for at this point in your plan.

karsten: The roadmaps should reflect the current status, active projects, and possible future projects of a product. Product owners should try to keep these pages up to date. Developers and volunteers can pick tasks from the roadmap to work on that they consider important to bring the product forward. Fundraisers can use the roadmaps to find funding for extensions to our products that product owners deem important. At least, that's the plan, and the current roadmap pages don't reflect that, yet.

Last modified 8 years ago Last modified on Jun 24, 2011, 7:37:14 AM