governance1Add my vote for this tag task_team1Add my vote for this tag create new tag
, view all tags

Task Team Governance

This topic describes the system used for TWiki 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 selected by the community, and is responsible for:
  1. Maintaining the TWiki 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 may be a function of another body (e.g. a TWikiFoundation) but that has yet to be decided. For the purposes of this description, it is assumed to be a stand-alone entity.

Task teams

One or more task teams. Task teams exists for the duration of something - for example, a TWiki release, a new version of the TWiki.org 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 TWiki ecosystem.

When the mandate of the administrative board expires, so do the charters of all task teams appointed by it. 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 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.

There is an obvious parallel between "Task teams", and the "Focus groups" previously proposed. The key difference is the charter, which grants rights as well as responsibilities.

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. "Higher authority" 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 TWiki 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.


See TaskTeamExamples

How do I form a task team?

Anyone can form a task team. Here's how:
  1. Visit CreateNewTaskTeam and fill out the form there
  2. Mail to mailto:twiki-dev@listsPLEASENOSPAM.sourceforge.net asking for the administrative team to rubber-stamp the charter. The administrative team will raise any questions, observations or conditions in the proposal topic.

Task teams awaiting charter

The following task teams are in definition, and have not had their charter agreed yet.

Active task teams

The following task teams are currently working.

Thanks to everyone who helped

This is a list of the task-teams that have completed their work. Well done, all!

Flying under the Radar

The following is a list of tasks/functions that are not addressed by the charter of any currently active or proposed task team. Please add/delete items as appropriate!
  • Newletter production
    • Currently handled by the Marketing meeting, which works fine but isn't a chartered task team, and doesn't have a defined scope.
  • Mailing lists
  • Sourceforge site
  • Press releases
  • TWiki.org web mastering - Support web
  • TWiki.org web mastering - Main web
  • TWiki.org web mastering - Codev web
  • TWiki.org online documentation - maintenance and merging to SVN

Pre-Berlin Discussion

More... Close I like the ideas laid out in this document. Thanks Crawford for this contribution.

-- MartinSeibert - 07 Aug 2008

I see this as a balanced and sensible tweak to the existing processes - the major improvement being that the interactions are specified, and clear limitations are set - exactly what TWiki needs.

-- SvenDowideit - 13 Aug 2008

I think this is a good proposal as it makes clear who's responsible for what in what time...

-- CarloSchulz - 13 Aug 2008

I agree with your stated likes/dislikes ("baseline"). And I like a lot your proposal. Incidenditally, I was discussing not one hour ago the way Debian/Ubuntu was working with a friend who is a Debian developer: They do not have a central SVN/CVS (just a plain directory), and they do not need one, as the notion of package have already divided the work in autonomous, independent "task teams" that are free to work as they want to come with solutions that may be competing with others, and that will be or nor accepted afterwards on their merits. I think your task teams proposal captures very well this spirit of linux "packages" allowing people to work independtly and try new things. For instance, you have the choice as a user between many email packages (exim/postfix/sendmai/qmail...) each one being compatible with the data, and developed independently

-- ColasNahaboo - 13 Aug 2008

Except for the election part - how is the Board of Directors different from the current Core team?

-- KennethLavrsen - 13 Aug 2008

It is different from the core team, in that their boundaries and time limits are clearly defined by the community.

-- SvenDowideit - 13 Aug 2008

Also, CoreTeam states "Members contributing large scale changes to the core, the Codev web and the TWiki docs". BoD members are not actually expected to do anything other than what is described above. Their main purpose is to keep TWiki "on mission", not to try and do all the work.

-- CrawfordCurrie - 13 Aug 2008

What I like about this proposal is that is less "abstract", but it has a lot of similarities with the original TWikiGovernanceProposal1:

  • Task Teams are equivalent to Focus Groups, but they activities are timeboxed and their field of action specifically framed. This is actually good: By timeboxing the activities of each group, we're forcing the group to act or be changed/removed.
  • Board Of Directors is equivalent to the TWiki Community Council. No more, no less. I like the rules that are laid of for the BoD.
  • Meet-up Teams is just another Task Team.
  • Technical Board is just another Task Team.
  • BDFL is a constitutional monarch. As long as the BDFL don't have the power to make a 540 degree turn in the TWikiMission, there is not much danger of power abuse.

So I see this more a refinement of TWikiGovernanceProposal1 rather than a completely different proposal. TCC should start writting the charters for the groups and teams, or appoint team to do that.

-- RafaelAlvarez - 14 Aug 2008

If this is TWikiGovernanceProposal1 refined then why is it presented as a new proposal?

Why the diverge instead of converge then?

I agree with Rafael that the task teams and focus groups are the same thing. There is nothing in TWikiGovernanceProposal1 that indicates these groups should not be time bound or not have charters. That could have been a simple refactoring of the TWikiGovernanceProposal1 topic.

I see the main difference between this and the TWikiGovernanceProposal1 proposals in the split between TCC and TTB. In the governance topic the TCC takes care of the "soft" things related to the community and appeal to the people in the community who is more interested in all the non-technical sides of a project and less on card core code. And then the TTB that can focus on the technical things.

This proposal has some real problems in my view. It is just the core team all over again with the main (and important) difference that this core team is elected for a time period. The election part is a good thing and a clear problem with todays core team. The TCC and TTB are also elected so both proposals has this key vital element.

The problem I see is that I do not wish to have features and roadmaps owned by en elite. Not even if I am part of that elite. These two things belong to the broad community.

The other problem I see is that I fear a BOD will either become very technical and see everything from a developers point of view or it will be dominated by non-technical that focus on documentation, meetups, politics, marketing, support of customers, etc etc. I think both are important and the split between TCC and TTB would ensure that both sides have the right people with the right interest and focus.

I do not see a problem having a TCC/TTB merged into BOD but then the members should divide themselves into roles so a less technical skilled person seeking help with a programming issue still knows that it is Crawford or Sven he needs to ask and not me.

One thing though. I would really like to emphasize that BOD, TCC, TTB or SOB ( smile ) teams are worth nothing if the people in them are not willing to do "all" the work.

I expect the people that stand up and gets elected to also be very active.

Question for Peter. What is the main reason that made you propose the Ubuntu model with the split in community council and technical board?

Question for Crawford. You know that to get to agreement we all have to move and convert into ONE proposal. I think Rafael tried to do that very well. How would you Crawford initiate a third proposal taking the governance and the task team proposals towards a common proposal with the best from both? Maybe wait till Peter has answered the question above.

-- KennethLavrsen - 14 Aug 2008

Kenneth, I can understand why you see the BoD as a reincarnation of the CoreTeam. What I fail to see is why you say that BoD is TCC+TTB. In my view, The BoD is exactly equivalent to the TCC, with an added twist: It "owns" the roadmap. Perhaps this point needs more clarification.

I'm with Kenneth that the roadmap should be decided by community, but the work to pick up the community needs from all the discussions, and condense it into a couple of bullet point should be the responsibility of "someone". What should the BoD/TCC do? Prepare the roadmap, put it for community discussion, moderate the discussion, record the result. That would mean that the BoD/TCC is responsible to make sure that the TWikiRoadmap is in sync with the community desires.

I would say that the same should happen with the TWikiMission.

OTOH, I see that the phrase "Reviewing proposals for, identifying, and rubber-stamping the charters for task teams" may be misread. As I understand it the BoD will review proposals to create new Task Teams, which makes sense given that they are the ones to actually appoint and monitor the Teams. Notice that the BoD does not decide who is the team leader ([unlike] the TCC [which] does), so the team should be self-organized. Feature proposal will still be managed with the current process until the community decide otherwise.

-- RafaelAlvarez - 14 Aug 2008

Thanks Rafael, you clarified things in exactly the same way as I would have done (I added a [couple of minor edits]). Kenneth, there were several reasons I didn't refactor the existing governance proposal.

  1. I I feel that the interim TCC should be in a position to consider things from several different angles. The only way they can do that is for those angles to be distinct.
  2. This proposal is (deliberately) not as detailed in terms of laying out roles and responsibilities for individuals, and a refactoring would have necessitated a lot of deletion, which I am sure would have resulted in a very negative reaction.
  3. There are a lot of open questions against the existing proposal that are still waiting for answers. It really has to stand alone until those questions are answered.
  4. I am not an interim TCC member, and do not feel I have the authority to refactor a proposal made by one.
I hope that at the end of the day the interim TCC will make up its own mind, and draw inputs from many sources, of which this is but one.

BTW you say I would really like to emphasize that BOD, TCC, TTB or SOB ( smile ) teams are worth nothing if the people in them are not willing to do "all" the work - that is exactly what I was trying to steer us away from. By assigning roles and responsibilities (usually to people who don't want them or can't do them) we end up shutting potential contributors out and freezing the decision engine. Yes, the BoD has to do a reasonable amount of secretarial work, but no-one expects them to do all the work. And if they try to work by ignoring the community, well, that's what the limited mandate is for.

-- CrawfordCurrie - 15 Aug 2008

I have been asked by TCC members to provide examples that reflect how task teams would work for "current twiki". I've done that at TaskTeamExamples.

-- CrawfordCurrie - 21 Aug 2008

It seems to me that the most important part of Crawford's proposal here concerns the operational concept of chartering teams to carry out specific tasks for the community. This makes a lot of sense. However, the proposal leaves some fundamental questions about the governance foundation that underlies the authority to grant such charters. Specifically, I'm wondering:

  • What is the makeup of the board? How many members? What are the terms? Are they staggered? Etc.
  • Who gets to vote for board of directors?
  • Do we need safeguards for conflicts of interest in Board decisions?

I'm particularly curious about the statement "When the mandate of the BoD expires, so do the charters of all task teams appointed by it." Does this mean the charters need to be explicitly renewed each time a BoD is re-elected or is this addressing the (hopefully rare) circumstance where a BoD is somehow given the boot en masse ?

-- LynnwoodBrown - 21 Aug 2008

Crawford: How can we join your proposal with the current proposal for the TCC and TBB into one concept, that all can approve? That would be a perfect preparation for the summit.

-- MartinSeibert - 25 Aug 2008

Lynnwood: The BoD is pretty close to the TCC, and a similar makeup (3 to 5 elected members) makes sense to me. I haven't thought through the mechanisms for voting, but I imagine it would be an online process, with each candidate stating their case, and an open public one-man-one-vote among people registered on t.o. I would have thought there should be a qualification for that (e.g. having registered for eat least 6 months). I don't know what sort of safeguards you had in mind, but the ultimate safeguards are open processes and the limited mandate (same as for any government). As for expiry of charters; I had in mind that a newly elected BoD should somehow be forced to review open charters, and that task teams should not become complacent about the continuance of their charter.

Martin: It seems to me that the interim TCC should be addressing that.

-- CrawfordCurrie - 26 Aug 2008

A few quick proposals:

  • BoD have 5-7 members. Still small enough to be effective, but absence of a couple does not cripple group.
  • Make terms staggered. This resolves issue of simultaneous turn-over (and resulting disruption of work). Extraordinary option for complete replacement of BoD is usually defined but should be fairly difficult.
  • Regarding safeguards against conflicts of interest, there are standard organizational processes for this. It becomes less of issue if basic checks-and-balances of power are in place.

The question of "who votes" is a core one what we have not spent much time addressing and is one of the more difficult in my mind, owing to the transient nature of most participation on this web site. I really don't have an answer but just wanted to draw attention to it again, as it is foundation to defining "mandate."

-- LynnwoodBrown - 27 Aug 2008

Post-Berlin Discussion starts here

I just hope that the solutions to all this political issues do not burden bug squashing.

-- FranzJosefGigler - 08 Sep 2008

Franz, it will if more people don't engage with the political solutions, because it will force the bug squashers to sort out the politics as well as the bugs.

-- CrawfordCurrie - 08 Sep 2008

After the successful Summit the political issues have become political tasks so all in all I expect more mental energy for bug squashing.

-- KennethLavrsen - 08 Sep 2008

I've been doing my best to keep up with TDO over the past months as these changes have become necessary and self evident. First, I applaud the entire group of programmers who would so much prefer to be squashing bugs instead of forming governments. I applaud you for your reluctant participation in a complete makeover of the TWiki community and its inner workings! Congratulations guys, you're doing great, and your hard work will pay off soon in the form of a well run, mature, and very successful open source project !!

So far, the above description of TaskTeamGovernance sounds like an excellent approach to me. And as you work through these tough issues & begin to implement solutions, my input is that I very much accord with the statement of beliefs, the focus on effectiveness, and the repeatability of the TaskTeamGovernance proposal.

I think it has been well thought out and would strike a healthy rhythm once the new process gets put into gear.

-- KeithHelfrich - 10 Sep 2008

I think it is already accepted by the community, just have a look a the task teams that popped up so quickly. This is the best evidence for acceptance.

-- CarloSchulz - 10 Sep 2008

I am not sure where to fit it in above. This is the governance schema based on our whiteboard sketch from the Berlin Summit 2008:

-- ArthurClemens - 10 Sep 2008

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng governance.png r1 manage 85.3 K 2008-09-10 - 21:26 ArthurClemens Governance schema based on whiteboard sketch Berlin Summit 2008
Edit | Attach | Watch | Print version | History: r33 < r32 < r31 < r30 < r29 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r33 - 2008-10-24 - CrawfordCurrie
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.