From KDE Community Wiki

Sample email

Hello XYZ team,

We've heard that this group is experiencing some difficulties, and the Community Working Group has been asked to intervene. We usually are asked to step into crises, while we would really prefer to work with groups to improve community. We've been developing a tool to help with that, and offer it to you to use (or not) as you please.

Notice that we don't focus on the issues under discussion, but rather how the team is functioning, with the goal of improving the conversation, and thus the creativity available.

No problem can be solved from the same level of consciousness that created it. - Albert Einstein

What is the ideal KDE Team?

The ideal KDE team has fun and is productive. The members trust one another enough to express honest feelings and thoughts about their project, as well as personal issues when appropriate. The team members support and encourage one another, and bring fresh information, resources and entertainment to the group.

The ideal KDE team is not only growing, but is always recruiting. Each team member is so happy with the group that new members are drawn-in naturally. Each team member blogs and writes in other places about the work, and about the team. Team members encourage one another to communicate publicly, and also to comment the code. At release time, team members pitch in to help, and celebrate their accomplishments. Team members look for diversity when they recruit, both culturally and in team roles.

In times of major disagreements, the ideal team thoroughly airs both facts and feelings honestly, and members do not attack one another. Everyone feels free to express themselves, everyone is heard, everyone feels valued, and every member supports the decisions reached, even if their own ideas were not accepted, because their concerns were taken into account.

The ideal team has not only an active group of coders, but also people who do bug triaging, documentation, mentoring, community, promo, forums, list, and IRC. The developers each do some of this work as appropriate, and also just talk with users. Enthusiastic users become testers, and then perhaps enter the team more formally to help out. As time goes on, a healthy team loses contributors too. However, they leave with fond memories, remain friends, and are often called upon for advice, feedback, or just to swap stories. Team members learn new roles, and train their own replacements all the time. Growing out of a role into a new one is more fun that burnout!

Team Health Check

Rate your team 1 - 5, where 1 is needs lots of work, and 5 is working excellently.

[ ] Is our team growing? How many members have we gained and lost in the last year?

[ ] How diverse is the team? Consider gender, age, team roles, time zones, language, etc.

[ ] Why are team members leaving? Do social bonds with departed members continue?

[ ] Do we encourage one another to learn new roles, and change those roles as time goes on? In other words, how do we stave off burnout?

[ ] What sort of recruitment of new team members are we doing? Is this recruitment increasing our diversity? Are we recruiting for diverse roles in the community as well (documentation, usability, testing, community, as well as coding)?

[ ] How often do team members meet up in the various fora, in meetings, and for sprints? How many of the team participate?

[ ] Do we have any sort of metrics set up that we can use to rate our progress?

[ ] How well is our code documented? (Undocumented code is a major roadblock to new contributors.) Is is a team value to Always Document?

[ ] How clear and up-to-date is our team documentation, such as our website, Techbase, Userbase and Community wikis?

[ ] How often do our team members blog about their work? Are their blogs all on Planet KDE?

[ ] Does our team contribute articles to The Dot?

[ ] What sort of training and guidance do we provide for our IRC ops, listowner, and forum administrators?

[ ] How many of our team members consider themselves to be leaders in the team? Do the non-coding members feel equal to the coders? Do all members of the team feel valued by the team?

[ ] How good is our bug triage, commenting, and bug closing?

Individual Health Check -- within the team, and KDE

Is my voice heard?

Are my ideas respected?

Are my emotional needs met? (within the boundaries of KDE and teams, this means appreciation for contributions and a sense of camaraderie)