[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [steering-discuss] Community bylaws


Hello Gianluca,


Le Sun, 14 Nov 2010 09:28:44 +0100,
Gianluca Turconi <ml@letturefantastiche.com> a écrit :

> Il 12/11/2010 18.40, Charles-H. Schulz ha scritto:
> > please read the first real draft of the Community Bylaws here:
> > http://wiki.documentfoundation.org/CommunityBylaws
>
> I need some clarifications. :)
>
> ***Questions***
>
> 1) Quotation from the draft: "The Engineering Steering Committee
> (ESC) is made of developers who are coopted (i.e, there's no need for
> election and there can be as many members of the ESC as needed)."
>
> question: *must* these developers be Foundation *members* at the same
> time too?

Your question is giving me the opportunity to clarify something which
is in the bylaws but it needs to be clearly written:
the foundation itself (the legal entity) will not/shall not have
members per se. Looking at the legal regime of foundations in France
and elsewhere, you need founders, but pretty much nothing else aside
money. So the Foundation will have donators, or even sponsors (above a
certain level of donations sponsors get one seat at the AB), the
Foundation organizes software development project(s) that have members
who are also "contributors to the Foundation". But the only "members"
of the Foundation are in fact the elected members of the BoD, and the
Foundation employees are employees and have a role inside the legal
entity, but are only employees.

I was surprised to discover that from a purely legal point of view (but
hey, I only have some primal law degree) the legal regimes of
foundations in Europe stress on donations, on accountability, etc. But
members are not a mandatory part. And I feel having two levels of
members, that is, one level to the project and another one to the
foundation creates a quite unfair and -as you often pointed out in a
recent past- a certain danger. The way it works , then, is that people
contribute to the TDF projects, their membership application gets
reviewed and granted, they get to vote to elect, among other things,
the BoD whose members are people just like them.

>
> possible issue: sponsored developers can be coopted by other
> developers and their employer can gain more powers/rights other than
> the seat in the Advisory Board.

Yes it is a risk, but then there is also social pressure, that works in
two ways. What would you suggest ?

>
> possible solution: sponsor's paid developers shouldn't participate in
> ESC as *single* persons. Contributions in their free time and
> following cooptation in ESC should be carefully evaluated from BoD or
> Membership Committee.

Hmm, I think it's a bit unfair to segregate corporate developers. On
the other hand, what I can propose would not apply to the ESC but to
the BoD: we can put a limit to members who are employees by the same
corporations to three persons max.

>
> 2) Quotation from the draft: "Engineering Steering Committee [...]
> This board is not elected but coopted by developers. There's no limit
> on the number of members of the ESC."
>
> Question: really no limit of members?! :)

:) yes. I don't expect the ESC to inflate to 24 members, if that's what
you're afraid of, but I'd rather see the ESC being one year at 5
persons and another year at 8 (no limit means; "we're technical people
debating technical topics, if we need someone else we'll bring him/her
in).

>
> possible issue: ESC members may coopt more developers just before the
> Chairman's election by gaining so a impromptu and really unfair
> majority in the special college for the Chairmain election's.
>
> possible solution 1: the chairman's election is not done by a special
> college, but according to a collective vote for each Committee (BoD,
> ESC and AB), made from their members based on a list of candidates,
> proposed or not by the committees themselves. There would be only 3
> collective votes expressed (quorum of 2 collective votes).
>
> possible solution 2: ESC has a maximum and preventively known number
> of members. The vote for this committee can be expressed from
> *members* that have contributed code to the project. This system
> needs a specification of "code contribution" and "role of sponsor's
> paid code contribution".


I'd go for the number 1 solution which I like, if others agree.

>
> 3) Quotations from the draft: "The board of directors appoints the
> Membership Commitee and can form any other adhoc teams or committees
> if needed. " and "The Engineering Steering Committee (ESC) [...]
> oversee the election of the BoD"
>
> Question: can the BoD in some "special" situation really form *any*
> other committee, ESC included?

No. ESC is statutory. Two things though:
there's only one class of members; and the ESC is not our ennemy :)
Regarding the special situation what I would see in this case is that
the BoD is in fact in charge of two things: it's the legislative power
of the community, but it is also the "board" of the foundation. Special
powers would thus exist in a setting where the BoD acts as the board of
the foundation.


>
> possible issue: the BoD declares that some "special" situation is
> met, then it forms (or dissolves?) the ESC so that a new ESC "helps"
> the old BoD members during the "overseeing" of the next BoD election.

No. Again, the ESC is not the source of issues: it's a technical
meeting place. What we would like to see -at least the members of the
SC as a majority- is a community where we don't necessarily antagonize
different members. We want a meritocratic community; and contributions
are the base of this. The BoD does not have to be hostile to the ESC,
etc. And if a corporation tries to take control of the project it will
always be possible. I'm not naive as to ignore that we are creating a
governance that will generate its own politics. But the base has to be
healthy: 1) contributors get to run the show 2) the BoD is in charge
for pretty much any important matter 3) there's a small team of
employees ensuring business continuity and execution with contributors
3) sponsors get to express themselves through the AB 4) we are
meritocratic and independent 5) no system is perfect, but for Free
Software it starts with people doing something, thus back to 1)

>
> possible solution: all Foundation members elect an independent
> committee that guarantees the regularity of the BoD election.
>
> ***end of questions***
>
> Furthermore, I think that the bylaws need more attention to *office
> incompatibilities" and *conflict of interests* for internal members
> and external sponsors.

I think you raise a good point. I'd like to suggest the provision of
the three employees of the same company at the BoD that I mentioned
above, and that the main (4) officiers of the Foundation are not being
employed by any sponsor but by the Foundation. What do you think?

Best,
Charles.

>
> Regards,


--
E-mail to steering-discuss+help@documentfoundation.org for instructions on how to unsubscribe
List archives are available at http://www.documentfoundation.org/lists/steering-discuss/
All messages you send to this list will be publicly archived and cannot be deleted

Follow-Ups:
Re: [steering-discuss] Community bylawsThorsten Behrens <thb@documentfoundation.org>
Re: [steering-discuss] Community bylawsGianluca Turconi <ml@letturefantastiche.com>
References:
[steering-discuss] Community bylaws"Charles-H. Schulz" <charles.schulz@documentfoundation.org>
Re: [steering-discuss] Community bylawsGianluca Turconi <ml@letturefantastiche.com>
Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.