-- 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 ( ) 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.

BTW you say I would really like to emphasize that BOD, TCC, TTB or SOB ( ) 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