Task Team Governance

Have a look at the list of existing TaskTeams.

This topic describes the system used for Foswiki operations, i.e. how the community creates projects, how it monitors, manages and closes out those projects. It applies to all types of activities, not just programming but also marketing, sysadmin, conferences, bar camps. Anything that needs an organisational framework, and is driven from the community, has a place here.

The system is just getting kick-started, so not all the pieces are in place yet. Please bear with us while we all go through the birth-pangs - and if you see something wrong, just fix it!

Statement of Beliefs

The system described below is based on the following beliefs:

1. Keep it simple
2. Recognise people for the contributions they make, and not for those they don't make
3. Don't burden people with unwanted responsibilities
4. Don't try to micro-manage people
5. Written processes have great power to guide people's actions
6. Experimentation is good
7. No lifetime appointments, of any kind
8. Act; don't wait for others to act

Administrative Board

The task team system is administered by an elected administrative board. This board is elected by the community, and is responsible for:

1. Maintaining the Foswiki Mission
2. Writing the roadmap, including identifying broad goals for future releases
3. Reviewing proposals for, identifying, and rubber-stamping the charters for task teams
4. Monitoring performance of task teams
5. Taking final decisions, when asked to do so by a task team.

It is important to understand that the role of the administrative board is not to govern; it does not dictate to the community how things will be done. The purpose is to provide administrative support for the community, such that community members have a framework within which they can work.

The administrative board is a function of the Foswiki Association board.

Task teams

Task teams are groups of people who get together to address a problem that they share. Task Teams exists for the duration of something - for example, a release, a new version of the website, a translation into Ancient Persian, or a range of T-shirts in bright primary colours. Task teams may vary in size from 1:N. Anyone can propose a task team.

Task teams operate within a limited charter, defined through negotiation with the administrative board, that defines the scope, authority, expectations, and if appropriate, rewards, of their work. Within the scope of their charter, they are the ultimate decision-making authority. Overlaps in charter between task teams will be recognised and resolved by the administrative board. Failing task teams will also be recognised and may have their charter modified or withdrawn by the administrative board. Charters are strictly limited in length. When a charter expires, then it may be renewed with the agreement of the charter holder and administrative board (for example, in respect of admin or other maintenance activities). Within the limits of their charter, task teams operate like mini open-source projects, with all the support of the surrounding Foswiki ecosystem.

The administrative board is made up of an odd number of community representatives, who each have an equal vote. Abstention is not permitted, though proxy voting (through another board member) is.

From inception to delivery a task team will draw on the skills of many people, and perhaps other projects. It is a given that the members of a task team will receive the maximum public credit for the work they perform. At this point in time it is unlikely that task teams will form sub-teams, but when they do, those sub-teams will also work under the limited charter system.

Over time, as the same tasks (such as building releases and admin) are repeated, their task team charters will become more refined. But at all times 100% visibility is maintained of who is expected to do what, and where decision making authority resides.

For example, the existing release management and feature request systems are very compatible with this. Each feature request is a task. The charter for that task will grant checkin rights, and require certain standards of test and documentation.

Each bugfix is a task, which can be covered by a generic charter for bug fixers.

We're aware that it may sound onerous to create these charters; but in practice it's a once-only task. Once charters are established, they can be re-used with only minor modifications. The key points are:

• the decision-making capability is devolved to the people who are actually doing the work. The administrative board is only referred to in cases where there is a lack of clarity, or a deadlock is reached.
• As charters evolve, they naturally document the processes Foswiki uses.
• There is nothing to stop commercial interests proposing task teams. Like any other community member, they get back in proportion to what they put in.

The power of a task team

• For all decisions concerning task team matters, the leader of the task team should be addressed via email. Alternatively two members of the task team can draw decisions like the task team leader if they do not respond within 5 business days.
• The Task team leaders draw decisions together with at least one other person of the task team. Those decisions are final, as long as nobody objects within 14 days of publication of the decision on foswiki.org. If at least 2 Foswiki-members object, a public voting for the decision shall be performed. The result is binding for the community.

Examples

See TaskTeamExamples

How do I form a task team?

Anyone can form a task team. Here's how:

1. First, have a look at the list of existing TaskTeams and make sure your undertakings don't already fit into one of the teams listed there.
2. Visit CreateNewTaskTeam and fill out the form there
3. The administrative board will see the form and act to rubber-stamp the charter. The administrative board will raise any questions, observations or conditions in the proposal topic.

Discussion

I don't believe a one-size-fits-all policy for task teams is most suitable. The scope of some teams may be relatively independent and so an autonomous approach is most effective. Other teams may need to consult closely with other teams or community members and so need to adopt a more collaborative approach in its decision making. --

IsaacLin - 19 Dec 2008 - 19:13

Commenting is disabled while not logged in