Kamaelia Project Processes

It's not what you do, but the way that you do it

This document serves to document the basic processes which will be used to manage the Kamaelia project going forward beyond April 2006.

This document is a subset of a larger internal document at work, and covers the aspects that people using Kamaelia may have an interest in. Specifically it excludes anything that relates to stuff that simply isn't Kamaelia related. This document has been written because the team is being split across multiple sites, which naturally fits well with community involvement.

This document is obviously subject to change depending on what we find works and doesn't work. It's based on best practice from other projects and so hopefully should work :-)

So what are we actually doing? See our Project admin section for IRC logs, meeting minutes, etc.

Project Lead

The project lead at present is Michael, however as far as possible all project admins are created equal, as are other developers.

IRC

The team will where practical be present on #kamaelia on the freenode IRC network, at least during office hours. Since Kamaelia is an open source project having a public meeting point is useful. This also allows for private off channel communications when it is necessary. For brainstorm discussions it has been noted that there is a need for a shared whiteboard tool. It is likely that this will take the form of a simple Kamaelia based system, since Kamaelia is at the stage where this is now feasible.

For more involved discussions the usual tools of email & the project bliki will be used (blog combined with wiki).

Weekly Meetings

The project will default to having weekly scheduled meetings at 11:00 am UK Time (GMT/BST depending on time of year) on the #kamaelia channel on the freenode IRC server network. If the friday is a UK bank holiday the meeting will be on the first working day before the bank holiday. The agenda for the meeting will be fixed, and as follows:

• Participant check - this will simply double check that all expected attendees are there. Whilst the meeting is primarily for the project team, it is expected, and desired to have external attendees should they wish.
• Note of the agenda - As you will see below, despite a fixed agenda, the agenda does contain discussion items. This allows for participants in the meeting to be aware of what is up for discussion in the meeting, and what is not.
• Activity reports -
  This forms 4 sentences (can be long sentences)
  These are posted by all participants simultaneously in a deft demonstration of copy and paste :)
• DONE - what's been done since the last meeting
• TODO - What I intend to do until the next meeting (not necessarily complete before the next meeting)
• BLOCKED - What is currently blocking someone from working.
• FOLLOWUP - This sentence is optional, and allows the team member to flag something that needs discussing after the meeting which may involve confidential information that should not be discussed in a public location.
• Discussion items.
• Maximum 4.
• They are to discuss how to proceed with an item, not to discuss the items themselves. The default options available are:
• Fix "now" (yes/no/defer)
• Assign responsible people and expectations (eg figure out how to do X by date Y).
• Assign group to meet some other time - this will include attendees, time and owner. (Time is wooley deliberately) Note this may involve waiting for the next face to face meeting to occur or scheduling a new one.
• Blockages are default to being additional items for discussion
• Check of note of date of next meeting - This is expected to be the friday at 10:30 the following week. If it's deemed appropriate, the attendees can decide to cancel the meeting the following week. Unless people are on holiday this process deliberately forces a meeting at least every 2 weeks, preferably weekly. It is suggested that if anyone has any BLOCKED items that cancelling a meeting the next week would be a bad idea.

The meeting is expected to have a fixed length of 30 minutes. If the number of team members increases, then this may grow to 45 minutes. A record of the meeting will be captured, but not formally reported (it may be informally reported).

This meeting approach has been seen to work for Canonical Ltd, and the PyPy project (an EU funded project) teams successfully.

Face to Face Meetings : Sprints

Why?

Since the team is distributed, it is desirable to build face to face meetings into the project management. The primary purposes of these meetings include (non-exhaustive):

• Working through particularly awkward issues (code/docs/architecture)
• Brainstorming purposes
• Project review
• Team building

It is expected that if the project has an imbalance of meetings in particular areas regarding these purposes, that extra meetings will be added to rectify the imbalance.

When?

The participants from the BBC will have internal meetings of this kind bi-monthly - specifically odd months of the year. The meeting will be held in the middle of the month, on a Friday, and last 1 full day - starting at 10:30am. (This is to enable travelling to the location of the meeting on the day of the meeting)

Sprints

If there is interest, we will organise public sprints to follow a similar purpose/pattern. If this happens, then multiday sprints will generally work backwards through the week. Some projects have a "sprinting" process, which involve multi-day meetings to work on specific areas of benefit to the project. If these become clearly desirable, the face to face meetings will grow backwards through the week for internal meetings (weds, thurs, friday). This is deliberate to curtail the possible desire to simply "add another day at the end of the meeting". It is expected that there will be 2-3 meetings a year that take this longer form.

If there is interest in having public sprints, these will be open to external collaborators. These should fall into the even months of the year where possible. The format of these will default to the same and the odd month meetings, but may involve different locations and times. It is suggested that at least one meeting occur at an open source conference, such as Europython for this purpose.

Agenda

The agenda/focus for sprints will be a decided prior to the sprint. How and where this will be decided will a discussion point for the 2 weekly meetings prior to the meeting, at the latest. This does not preclude a "hot issue" being dealt with instead.

Reporting

The project proposes to document once a month, at the end of the month, the following:

• What's been STARTED
• What's IN PROGRESS
• What's been DONE
• What's BEEN BLOCKED and IS BLOCKED, and what the proposed approaches for working through those blockages are, and if what the approaches were for working through the former were.
• What other OPTIONS have come up during the month that are being considered or noted.
• These may require discussion as to whether to move forward, or they may have been simply discounted. The idea is to document these ideas and options.
• Anything else NOTABLE (might not always be present)

Unless these contain confidential information, these will end up on the Kamaelia project website here.

Subject to Change

The entirety of this document is subject to change if the processes described are not found to be useful/working.