[squeak-dev] Terms of Reference: discussion is open

Jecel Assumpcao Jr jecel at merlintec.com
Thu Nov 5 20:26:22 UTC 2009


I pointed out to Keith on IRC a while ago that it was simply impossible
for the board to "break the rules" since we have never had any rules. He
has kindly suggested a possible set of such rules and I think that is a
good starting point for a discussion.

In the page in the blog I have added some links to the rules or
organizations of other Free Software projects. Most other project have
no rules that I could find and even these are pretty informal.

Given that our community is pretty small, that elections are frequent
(every 12 months) and that re-elections are very common (most of the
current board was part of the previous one), I don't think most of the
proposed rules would help very much. I'll make a brief comment on each
one:

1) [board selects team and lets it decide all else]

This wasn't done by the previous board for the web team: one group
proposed using Seaside and another Aida such that by picking a team a
technical decision was being made indirectly. I think that this will
often be the case for future issues as well.

2) and 3) [avoid conflict of interest, board member should follow same
rules as everyone else]

This was violated in a big way with the creation of the Trunk
repository, where all board members automatically became core developers
along with several other people. In general, however, board members have
had enough sense of fair play that this hasn't yet been a big problem,
in my own opinion (other people might feel very differently).

The problem with these two rules are that it isn't very easy to check
that they are being followed since "unfair" is rather subjective. I
would rather see this as part of some "declaration of principals" than
as a "term of reference", but perhaps there isn't much difference
between these.

4) and 5) [how teams and the board should interact]

This is actually how things were done in most cases. The one exception
was the Trunk thing (if you consider that a replacement of 3.11 rather
than a third effort parallel with the on-going 3.11 and 4.0 ones). So I
agree with this one.

6) [no general rules for internal team communication]

Sure.

7) [board delegates all real work to teams]

I interpreted the results of this year's election as a desire for a more
"hands on" board that makes technical decisions directly. So I don't
think the community would be happy with this rule.

8) [respect decisions from previous board]

Like I said above, most of the current board was also the previous one.
They changed their minds about some things and I don't think there
should be a rule preventing them from doing so.

9) There should be a grievance procedure and an equal opportunities
policy including disability awareness

I didn't attempt to paraphrase this because I didn't understand it.

One thing that Keith mentioned, a "vote of no confidence" followed by an
ad hoc election, didn't get included in this list. Without that I don't
see what the answer could be to "what happens if the rules get broken?"

Given that the next election is at most 12 months away and that any ad
hoc election would probably pick the exact same board that was just
kicked out, I am against such a rule. But without it, none of the others
"have any teeth".

I would be happy with general principals rather than rules, and the
board has previous tried to define that:

http://squeakboard.wordpress.com/our-mission/

-- Jecel




More information about the Squeak-dev mailing list