Changes between Version 22 and Version 23 of org/process/SetUpProjectMgt

Jun 24, 2011, 7:37:14 AM (8 years ago)

Answer Nick's comments


  • org/process/SetUpProjectMgt

    v22 v23  
    6666 - 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.
    6767> nickm: Adding a new "project" ticket type seems like a great idea, if we can actually distinguish projects from nonprojects.  I bet we can.
     68>> karsten: Yes, we can search by ticket type.
    6970 - We shouldn't maintain a manual list of active projects in the wiki like the current one on [wiki: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 [wiki:org] for how such a list of active projects would look like.
    7273 - 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.
    7374> 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.
     75>> 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.
    7577 - 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.
    7678> 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.
     79>> 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.