Ubuntu IRC Council Roadmap

...back to Roadmaps

Building Your Roadmap

Each goal in the roadmap has a set structure which you should stick to. This is how it works:

  • Objective' - An Objective is a goal that you want to achieve. Summarize your objective here in one sentence (e.g. 'Exhibit Ubuntu at OSCON' and 'Create Lucid Marketing Materials').

  • Success Criteria - This is a statement that can be clearly read to determine success on the above 'Objective'. This needs to be as clear as possible and not vague: it will indicate if you achieved the 'Objective' (e.g. 'A successful exhibition at OSCON' and 'Lucid website buttons, banner ads and wallpaper provided for LoCo Teams').

  • Actions - This is a set of steps that need to be executed to achieve the 'Objective'. It is recommended that if someone volunteers to commit to delivering on an action, you put it in brackets (e.g. 'Print out LoCo logo on a banner (Jono Bacon)'). There can be multiple actions for each Objective.

  • Blueprint (optional) - It is recommended to use a launchpad blueprint for your objective. Launchpad isn't just for developers, but is also great for community tasks.

  • Driver (optional) - If someone is coordinating this objective and helping those involved to deliver on their actions, list that person here. If you're using a blueprint it's especially convenient to mark the driver as the Drafter and Assignee of the launchpad blueprint.

Tracking Progress

Here are some tips on tracking progress on your roadmap:

  • Review it at meetings - your roadmap should be an agenda item at every meeting your team has. Review progress, identify problems, ensure everyone is clear on what they are doing and unblock blockers.
  • Review mid-cycle - it could be useful to review progress on the roadmap halfway through the cycle in detail.
  • Evaluate at the end of a cycle - when the cycle is complete, review the roadmap and see how much the team achieved.


  • OBJECTIVE: Document the operator assessment process

  • SUCCESS CRITERIA: Document an agreed-upon process that outlines how the IRC Council evaluates an Operator.


    • Review the Operator Guidelines to ensure that they are accurate (Benjamin).
      • Ops should be able to govern all channels to the same level of expectation?
    • Work with Benjamin to assess the elements involved in the assessment (Jussi).
    • Document these elements on the Ubuntu wiki (Jussi).
    • File a bug for this document not existing and assign to the IRC Council (Benjamin).
    • Community Council offers input on this document (Daniel Holbach).


  • OBJECTIVE: Community Council assist the IRC Council in developing a application process for Operators.

  • SUCCESS CRITERIA: A completed and well-documented application process.


    • Gather requirements for good operator best practice from the IRCC (Jussi and Benjamin).
    • Develop a recommended set of requirements for operators (Jussi).
    • Have the CC offer input on the document (Full Community Council).


  • OBJECTIVE: Prune channel access lists

  • SUCCESS CRITERIA: There is an access list that contains active and trusted operators


    • Pull channel access lists from core channels and put into LP team with expiry dates
      • Determine the work required to do this in an automated way (Jussi)
      • Implement the feature (Terence and Ben)
    • File a bug against LP for expiry email custom content

  • DRIVER: Benjamin Rubin.

  • OBJECTIVE: Membership Approval

  • SUCCESS CRITERIA: Well-documented process for Ubuntu IRC Membership

    • Short backlog of applicants
  • ACTIONS: Document IRC-specific requirements for Ubuntu Membership

  • BLUEPRINT: <link>

  • DRIVER: Benjamin Rubin, Jussi Schultink (Daniel Holbach can help out)

Roadmaps/Lucid/IRCCouncil (last edited 2009-11-24 00:08:25 by c-67-164-44-209)