Re: [gentoo-project] [GLEP 39 overhaul] Do we want to make changes to the role of the council?

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22-04-2010 01:23, Richard Freeman wrote:
> Note - references below to specific teams like Devrel are purely for
> illustrative purposes.  I don't intend to suggest that the council
> actually needs to step in right now to fix anything in any of these teams.
>
> On 04/21/2010 08:27 PM, Jorge Manuel B. S. Vicetto wrote:
>> On 18-04-2010 11:58, Richard Freeman wrote:
>>> All other positions of leadership/etc exist to facilitate day to
>>> day work.  All are subordinate to one of these two bodies.  The
>>> council may be voting enact or revoke policy on behalf of any
>>> project/etc, and may make administrative decisions regarding
>>> project leads/etc.
>> I'll try to write my ideas on this subject in another reply to this
>> thread, but for now I'll just say that we should try to find a
>> balance between individual projects and their elected leads and the
>> council. Furthermore, we have some special projects like Developer
>> Relations and Infrastructure that need particular care as their
>> "subordinate role" is either not so clear or not so desirable.
>
> Here is my concern.  I didn't vote for the lead of any of Gentoo's
> projects.  At best I might get a chance to vote for one or two.
> However, I do vote for the council.  So, the council represents the
> developers of Gentoo as a whole.  If a project team wants to do
> something that the council considers detrimental to the distro as a
> whole (though perhaps it is optimal from the POV of the single team),
> then they should have the right to step in and make amends.

My concern here is the idea that the council should be able to "disband"
a project or turn it around 180 degrees. If we open the door to this,
then we'll be throwing away the principles that any developer can create
a project, that a team acts as its members choose to and that in the end
some choices fall to those who do the work.
I don't disagree with the council being able to influence or to
cooperate with a particular project, but I don't like the idea of it
having "nukes". Also, you'rd arguing that if a developer can't have
influence on a team, they could try to go around it straight into the
council. The vast majority of Gentoo projects are open to membership and
that should be the preferred way to have influence on them - by sharing
the load and working with the other members. Besides, if the council
were to "disband" a team or try to force a policy on it, how do you
think that would work if there were no team members left and no one
stepped up?
If and when a project or an individual developer exhibits a behaviour or
takes action that compromises Gentoo or detriments its image, we should
have tools to address that. We already have some tools though.
Individual developers, depending on their actions, may be subject to
DevRel action or have their access suspended by the infra team. If the
issue has a legal base, the Foundation Trustees can be called to
intervene. Finally, in extreme cases, the council can also have a word
regarding individual developers and or projects.

> The council and trustees are the most democratic bodies in Gentoo, and
> it is fitting that they ultimately wield the most power.

Gentoo isn't exactly a "democracy" and therefore such comparisons
usually are not adequate for us.

>> But we have a policy on how to deal with developers and the eagerness
>> on the idea to throw it away and just let the council (the single
>> body council?) do what it wants, is very disturbing to me.
>
> Who voted to create this policy?  Who gets to change it?  If I want to
> change devrel policy, how would I do that?  Suppose 85% of the Gentoo
> devs want to change it?  Right now they'd need to somehow convince a
> majority of the members of Devrel to change the policy, or elect a lead
> that would.  If the members of devrel are mostly from the 15% who
> disagree with the change then that might not happen.  If devrel just
> boots the council on some pretense, should the council not be allowed to
> hear their own appear since it is a conflict of interest?  My point is
> basically that closed groups like devrel should always be subordinate to
> an elected body - either the trustees or the council.
>
> If you look at any other serious organization the purpose of committees
> and bureaucracy is to serve the organization, and the organization is
> represented overall by the board of directors, who are elected by the
> members/shareholders/etc.  This system works well - ultimately the
> members have absolute authority in elections, but the directors oversee
> things from time to time, and the committees and bureaucracy deal with
> the day-to-day.

Gentoo (the distribution) is not a Corporation, so that comparison isn't
adequate as well.

Like it or not, a body like Developer Relations isn't democratic by
nature. I don't think it ever had open membership as one of the concerns
is that its members have some particular traits. Thus, as far as I know,
all current and former members were always invited in.
But Developer Relations isn't a "Boy's Club" or the only "not so open"
group in Gentoo. There's also User Relations. The infrastructure team,
for its own responsibility and abilities, as far as I know, has always
invited members in and doesn't have open membership. To a certain extent
the QA team has worked that way too and I'm sure most of us would like
QA members to exhibit certain qualities. Then there's PR.
So, as I said, some teams have particularities that need to be taken
into account. Also, some policies like Developer Relations are never
good candidates for a referendum. To have an effective and adequate
policy, you want people to work on it with cool blood, to leverage some
experience on it and not to be concerned with the document's
"popularity". If DevRel were ever to try to introduce arbitrary measures
in the policy contrary to Gentoo's interest and or of questionable
nature, the Council should obviously have a say. I would say Trustees
could also be called into action, but I don't see a direct way for them
to intervene as long as the change impact only the people working on
Gentoo and or the way they work on Gentoo and not the distribution in
itself, but nothing prevents the Council asking for their help if they
see it fit.

> For example, the KDE team shouldn't be running every decision past the
> council.  They probably should try to communicate to the community what
> they're up to, and they're one of the teams I'd actually consider among
> the better in this regard.  If the council sees a big problem then they
> should be able to step in if necessary, but they should of course use
> discretion before doing so.

A former council did have some influence, not directly in the KDE
project, but by having DevRel evaluate and act on one of its members -
at the time the Lead. That action did had a profound impact in the
project - it almost killed it and it took a long time for KDE to get
back in shape. For this discussion the relevant part is that the action
was done by DevRel, it was about an individual member behaviour and even
though it followed procedure it still raised much concern about the
council influence - so one can only imagine what would have been the
reactions if council were able to take action directly. Furthermore,
such influence in the end lead to most of the existing active members
leaving the project and if there had been no new blood coming in, we
might had been left without KDE on Gentoo. So a direct intervention by
the Council on a project may have dire consequences.
To be clear, I do want the Council to have influence over Gentoo, but I
don't like the idea of "carte blanche" and therefore am concerned about
the degree and method by which the council should "leverage" its influence.

> That's really all I'm saying.  The council should not wield its power
> with a heavy hand, but it should not be prevented from intervening on
> behalf of the community when necessary.  To be honest, the complaint
> around here (perhaps warranted, perhaps not) seems to be more that the
> council doesn't do enough - I'm not sure that any council in memory
> would be eager to micromanage every project team.  However, this is why
> devs should consider maturity when electing the council.
>
> The council doesn't do what it wants - it does what the developers as a
> whole want.  By all means throw in a recall provision in the GLEP if you
> want, but if the dispute is between the council (elected by all) and
> some project lead (maybe elected by a few devs they work closely with),
> I'd say the council will have the best overall perspective.
>
> Rich
>

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJL0DXWAAoJEC8ZTXQF1qEP8MgP/2NQP4CXYAzYd7UNP9QrQdq7
pE4vOyzEcXys8Bo0HQzOozNDFluDgVAAe+LreQ38dbU5FworyGpf48llG9q4R1VA
Hemq0P21UJ+VmVGzMYnRIhZ7eSXdYOSs/W9CeT3VNSwZBBVIlv+W4/uBl/3FPtv2
321U/l1kiC7oSml+33ejnhnXjxZrz8y3XvoeQ6c796kKiumVJ/T9zi/uWsk/xeOZ
S72tz7tPgOnVxrz3SD2ltTRNsdv94WA6QvnHxZwfjcsi6lNIITXxxsnoV14UIPub
i91BMjiBP7YTgujhG6jtzn/L03dTgzSj6wnoZtpkFxMiVC2Sqbzq3WNuDVkBxkyR
NhCmvqpk+kEPG3O9uUm67B8EV66gd4Sn3u5Qjm1iFNGui7pX8e15E1YhUUoTvTZv
iaL35MzoRh4O9XkNhJWiOl8S5mPeyDcg6j5MmLKYprmHSJpTmZGI+AVbDX16uTzj
Ra6Y0Wxgm559t7jpM7vlsF98OV2WxvFX9bLCwi0v+a0Qxlszenj1KgiLR9q8pWmU
BfdMPbHAxtPkKDUpijeLF8R9N831MAgbgzwO46cGBYeIUmBNqcZMxy0x21WJU37U
77CdoBtkdYT9EiLCRXKUq6uKq3fZnsApq0pa5ZnUzcqvN/2+WhCzsw9wcVfwQGla
hqZ6665ij/t1/OIVeYQn
=/wqa
-----END PGP SIGNATURE-----