ImprovingCommunication

Differences between revisions 3 and 4
⇤ ← Revision 3 as of 2010-05-10 11:03:16 →
Size: 3861
Editor: 217
Comment:
← Revision 4 as of 2010-05-12 17:49:34 → ⇥
Size: 5219
Editor: 217
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
 * '''Contributors''':  * '''Contributors''': ubuntu-qa team
Line 12: Line 12:
== Release Note ==

This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

It is mandatory.
Line 20: Line 14:
This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified. The QA team could do much better with communication. IRC meetings have less a less participation from the community and Canonical QA members, the QA blog is not that used and the meeting notes are not send to the mailing list.

We need to identify the several problems that we are having in the QA team in terms of communication.
Line 24: Line 20:
== Assumptions ==  * charlie-tca is an active tester and triager, but he cannot attend the QA meetings in the current time (17:00UTC). As no notes are never sent to the ubuntu-qa list, he never keeps up on what is going on.

 * Paul would like to have updates on what the QA team is doing, but the weekly newsletter never shows anything about QA. The QA Blog only has bug day announcements.
Line 28: Line 26:
You can have subsections that better describe specific parts of the issue. === Meetings ===
Line 30: Line 28:
== Implementation == We will rotate the chair of the meetings every week. The chair will take care of: setting up the agenda and call for topics, drive the meeting and send meeting notes to the mailing list. To prepare the agenda, the chair can use the following template, as some of the topics are recurrent.
Line 32: Line 30:
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: We will rotate the time every week, having two fixed times. First week will be 17:00 and the following week 17:00 - 8 or 17:00 + 8. Both are available. We will set up a doodle poll to select the meeting times.
Line 34: Line 32:
=== UI Changes === We need a way to measure participation. 6 weeks after these changes have been put in place, we will check if the participation raised and we will also ask for feedback in the mailing list.
Line 36: Line 34:
Should cover changes required to the UI, or specific UI that is required to implement this ==== Meeting Template ====
Line 38: Line 36:
=== Code Changes ===  * Actions from previous meetings
 * Small roundtable
 * SRU status
 * Bug day status
 * "Featured team" (if we have one for that meeting)
 * Any items to send to the newsletter?
 * Selection of the chair for week+2
Line 40: Line 44:
Code changes should include an overview of what needs to change, and in some cases even the specific details. === Blog ===
Line 42: Line 46:
=== Migration ===  * The design team has a website (http://design.canonical.com) that aggreates their blogs and it also has ways to introduce content in it. We would change the current landpage (http://qa.ubuntu.com) for this wordpress instance. We will add a Ubuntu template for it.
Line 44: Line 48:
Include:
 * data migration, if any
 * redirects from old URLs to new ones, if any
 * how users will be pointed to the new way of doing things, if necessary.		 === Newsletter ===
Line 49: Line 50:
== Test/Demo Plan == The Ubuntu Weekly Newsletter is a good way to communicate news to a broader audience. Developers or people actively committed in one of the teams usually don't read the newsletter, as they normally are aware of what is happening with mailing list. But if we want to reach a wider audience, sending regular announcements to the newsletter seems like a good idea.
Line 51: Line 52:
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage. During the IRC meeting there will be a recurrent topic about the newsletter at the end of the meeeting. We will discuss if anything that was said during the meeting could be of interest and we will select who is writing it and send it to the newsletter.
Line 53: Line 54:
This need not be added or completed until the specification is nearing beta. == Action Items ==
Line 55: Line 56:
== Unresolved issues ==

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.		  * [xdatap1] Prepare the doodle poll asking for fixed meeting times (17:00UTC is fixed, we need another one)
 * [apulido] Prepare the announcement to the ubuntu-qa team about what was decided about meetings and asking members to vote
 * [apulido] Talk with the design team about creating a template for wordpress for Ubuntu
 * [apulido] File an RT ticket to get a wordpress instance running in qa.ubuntu.com
 * Prepare the call for feedback to send to the ubuntu-qa mailing list
 * Study how the participation increased (or decreased) and send feedback to the mailing list

Summary

A session where we're going to discuss how to improve the communication with our community on Mailing lists, IRC Meetings, events, etc.

Rationale

The QA team could do much better with communication. IRC meetings have less a less participation from the community and Canonical QA members, the QA blog is not that used and the meeting notes are not send to the mailing list.

We need to identify the several problems that we are having in the QA team in terms of communication.

User stories

  • charlie-tca is an active tester and triager, but he cannot attend the QA meetings in the current time (17:00UTC). As no notes are never sent to the ubuntu-qa list, he never keeps up on what is going on.
  • Paul would like to have updates on what the QA team is doing, but the weekly newsletter never shows anything about QA. The QA Blog only has bug day announcements.

Design

Meetings

We will rotate the chair of the meetings every week. The chair will take care of: setting up the agenda and call for topics, drive the meeting and send meeting notes to the mailing list. To prepare the agenda, the chair can use the following template, as some of the topics are recurrent.

We will rotate the time every week, having two fixed times. First week will be 17:00 and the following week 17:00 - 8 or 17:00 + 8. Both are available. We will set up a doodle poll to select the meeting times.

We need a way to measure participation. 6 weeks after these changes have been put in place, we will check if the participation raised and we will also ask for feedback in the mailing list.

Meeting Template

  • Actions from previous meetings
  • Small roundtable
  • SRU status
  • Bug day status
  • "Featured team" (if we have one for that meeting)
  • Any items to send to the newsletter?
  • Selection of the chair for week+2

Blog

  • The design team has a website (http://design.canonical.com) that aggreates their blogs and it also has ways to introduce content in it. We would change the current landpage (http://qa.ubuntu.com) for this wordpress instance. We will add a Ubuntu template for it.

Newsletter

The Ubuntu Weekly Newsletter is a good way to communicate news to a broader audience. Developers or people actively committed in one of the teams usually don't read the newsletter, as they normally are aware of what is happening with mailing list. But if we want to reach a wider audience, sending regular announcements to the newsletter seems like a good idea.

During the IRC meeting there will be a recurrent topic about the newsletter at the end of the meeeting. We will discuss if anything that was said during the meeting could be of interest and we will select who is writing it and send it to the newsletter.

Action Items

  • [xdatap1] Prepare the doodle poll asking for fixed meeting times (17:00UTC is fixed, we need another one)
  • [apulido] Prepare the announcement to the ubuntu-qa team about what was decided about meetings and asking members to vote
  • [apulido] Talk with the design team about creating a template for wordpress for Ubuntu
  • [apulido] File an RT ticket to get a wordpress instance running in qa.ubuntu.com
  • Prepare the call for feedback to send to the ubuntu-qa mailing list
  • Study how the participation increased (or decreased) and send feedback to the mailing list

BoF agenda and discussion

Agenda

  • Meetings
    • Small round table
    • Rotation on chairing / sending notes
    • "Featured team"
  • Mailing lists
    • ubuntu-qa
    • ubuntu-bugsquad
  • Blogs
    • QA blog
    • Personal blogs
  • Newsletters
  • Twitter

Discussion

  • Meetings
    • The feel Canonical QA team
    • We don't ask the community (call for topics)

    • LoCo Teams

    • Brainstorming
    • Making decissions
    • Lack of agenda
    • Roundtable per team
    • rotation on chairing / sending notes
    • Suggestion on alternate times - 2 fixed times
      • Set up a doodle poll to ask for times - Paolo
    • Selecting the chair at least 2 weeks in advance
    • We need a way to mesure participation
    • Way to (automatically) send transcript of meeting notes to mailing list
    • "Featured team"
      • Representatives from other teams v.s. QA people only
  • Mailing lists
    • ubuntu-qa
      • Introducing themselves, and then you don't hear from them
      • Pointing people to documentation - Once a cycle.
    • ubuntu-bugsquad
      • A way to communicate ways to help
      • Bug conversation needs to happen here
    • ubuntu-bugcontrol
      • Only for reviewing applications to the bug control
      • apport crashes
  • Mentoring?
    • Having a email template to send to new people
    • A way to help people finding a job
  • Blogs
    • QA blog
    • Personal blogs
    • The design team has a blog that also aggregates their personal blogs.
      • We want that!!!!
  • Newsletters
    • Good for people not that involved
  • Twitter

CategorySpec

QATeam/Specs/ImprovingCommunication (last edited 2010-05-12 17:49:34 by 217)