Goal

Plan

Measures

Start Karmic with a well defined plan

Compile community and roadmap input. Gather input from desktop team (including community members)

Are roadmap calls documented? Are brainstorm suggestions reviewed?

Filter based on the Ubuntu philosophy to sort the input

Was a filtering and sorting process documented? Was there visibility into this process?

Ensure the proper set of blueprints are prepared for UDS

Did the desktop team go to UDS with a complete set of blueprints? Were the blueprints sufficiently fleshed out?

Facilitate useful discussion and capture output thereof

Was the output of each session captured and published? Were the right people at each session?

Facilitate and track development work throughout Karmic cycle

Identify the set of blueprints that will be developed for Karmic

Was there a set of tagged and prioritized blueprints available for community viewing 3 weeks after UDS? Does each engineer have an appropriate number of blueprints assigned?

Ensure that engineers breakdown work from each blueprint into discrete tasks

Does each blueprint have clearly identifiable subtasks associated with it? Was the identification of subtasks a natural extension of the existing development process?

Publish burn down charts to track progress

Was a burn down chart presented at each weekly meeting? Was the creation of burn down charts automated in any way?

Facilitate identification and fixing of the most important bugs identified by QA and users

Don't let bugs languish assigned to "canonical-desktop-team"

Were bugs assigned to "canonical-desktop-team" moved to "unassigned (ct-rev)" or assigned to a team member within 48 hours?

Get "Critical" or "High" importance bugs fixed quickly

Were "Critical" bugs addressed within 48 hours of being assigned to an engineer? Were "High" bugs addressed within a week?

Monitor overall bug numbers

Were incoming rates and fix rates presented graphically? Were hot spots addressed?

Differentiate bugs that engineers will fix within a release from bugs that are assigned to them, but won't be fixed in the release

Was there a differentiation established between bugs that would be addressed versus other bugs? Were engineers empowered to "not fix" bugs that they couldn't reasonable address?

Goal

Plan

Measures

Promote best practices for application developers new to Ubuntu

With the community and desktop team define a standard set of tools, language(s) and frameworks for developers to use for building common applications to run on Ubuntu

Are such standards documented publicly? Did the creation of such standards follow the normal community related procedures, such as a blueprint, UDS discussion, ubuntu-devel list?

With the community and desktop team define programming practices, such as directory structures, managing dependencies, etc...

Publish and promote these standards

Were these standards sufficiently publicized to, for example, be referenced on the ubuntu forums? Were any applications explicitly build to leverage these standards?

Development a standardized and easy to use build system, consistent with development best practices, and PPAs, leveraging and consistent with existing build methodologies and tools

Work with the right desktop team engineers to create a blueprint for a tool that will very easily create and publish an application following the aforementioned standards

Was there a blueprint created, discussed, and ratified at UDS?

Build and release the tools, early and often

Was there a project and repository created for the new build tool? Was user feedback gathered and used during development? Did the system ship as part of Karmic?

Enhance the "Add/Remove" software experience

Working with the community and the Canonical User experience team, create and execute a development plan in Karmic to make Add/Remove more discoverable, easier, and cooler

Was there a blueprint and spec created for the desired changes? Were these changes implemented? Was feedback gathered to confirm that issues were in fact solved by these changes?

Goal

Plan

Measures

Facilitate excellence on the Desktop

Reach out to "Canonical Upstreams" to understand their plans and needs

Have we linked as appropriate to their documented plans? When their plans aren't documented, have I captured their plans and documented them for the desktop team?

Identify specific dependencies on the desktop team, and manage those as work items release to release

Is there a list of dependencies for Karmic? Are specific engineers assigned work items to fulfill those dependencies? Is that work being tracked as part of the normal work item tracking?

Tweak plans for supporting these teams as their plans evolve

Is there a recurring call with canonical upstreams to stay abreast of progress and evolving plans? Are the work items updated to reflect these changes?

Provide hands on support to these teams in terms of packaging, best practices, and whatever else it takes to get the job done

Do the other Canonical teams know their primary contact? Do at least half of the desktop team members have at least on work item assigned to them at some point in Karmic for supporting a non-platform team?

Create a virtual cross-company translation team

Organize a call, perhaps recurring, with involved parties

Has a group phone called occured with a of people from Canonical teams including Rosetta, OEM, Soyuz, etc...?

Establish and achieve company goals for improving the translations system

Has a wiki page or other appropriate forum been established to Canonical-wide goals? Has at least one project been embarked upon during the Karmic time frame?

Goal

Plan

Measures

Represent team and desktop product

Be present and active in key community forums, such as irc channels and confences

Am I logged into key community channels during working hours? Do the key community players in those channel recognize me, and feel comfortable approaching me? Have a presented at at least one non-Canonical event?

Represent the goals of the desktop product as well as advocate for the needs of the team within Canonical

Does the desktop team have sufficient resources to accomplish their goals? Is the desktop team mission statement reasonably up to date?

Maintain high team morale

Recognize team and individual contributions both publicly and privately

Have I called out team or individual contributions in about half of the weekly team meetings? Have I shared kudos for team members with senior managers? Do team members report receiving appropriate credit for their contributions?

Reward high performance via appropriate raise, recognition, and other rewards such as time off as appropriate

Have a written detailed an persuasive feedback in review documents? Do team members feel that they are getting a good deal from Canonical? Have I shared kudos for team members with senior managers? Do team members report receiving appropriate credit for their contributions?

Delegate responsibilities and empower engineers

Do team members have clearly defined areas of responsibility? Do team members behave as if they "own" their areas of responsibilities? Do team members take personal responsibility and action for enhancing their areas?

Identify signs of burn out, and pro-actively work to avoid or mitigate it

Do team members take days off after stressful or intense periods of work? Do team members approach me when feeling overwhelmed or burned out? Have a I successfully reallocated work or otherwise matched resources to needs when needed?

Maintain high performance and excellence in contribution across the team

Provide career guidance to help high performers to continue to progress in their careers

Do I have a regular call with each team member? Do team members have reasonably detailed written goals? Do those contain stretch goals, or career oriented goals? Do team members feel that they have opporutnity for career growth at Canonical?

Provide actionable goals and plans for weaker performers

Have weaker performers been provided with clear feedback regarding their performance? Do they have a clear plan for achieving acceptable or better performance?