[gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?

[Alec Warner]

On Thu, Jul 2, 2009 at 7:54 AM, Tobias Scherbaum<dertobi123@g.o> wrote:
> Ned Ludd wrote:
>> The devs have a voice one time of the year: when it comes time to vote.
>> But what about the rest of the year? What happens when the person you
>> voted for sucks? You are mostly powerless to do anything other than be
>> really vocal in what seems like a never ending battle. That needs to
>> change. I'm not quite sure how. But I'd like to see the dev body have a
>> year-round voice in the council. Either via quick votes year-round
>> on topics or simply by having discussion in the channel. Devs should have
>> a right to voice their concerns to the council and engage in interactive
>> conversations without being labeled troll.
>
> I'm not sure about that, but we can easily give it a try.
>
> What I'd like to see for sure is a formal rule on who can decide to
> modify or change parts of glep 39. As it's the council's constitution
> somehow, we have two options from my pov (besides that a former council
> did decide the council itself can change it's rules):
> - a large majority (at least 5 out of 7) of council members needs to ack
> the change
> - changes to glep 39 require a vote with all developers participating
> and a large majority (2/3 or 3/4) needs to ack the suggested change

Just FYI, Gentoo is lucky if 1/2 of the devs vote; so I assume here
you mean large majority of the people who actually voted.

>
> Also I'd like to require commit messages to gleps (and especially glep
> 39) being useful and denote based on which decision by whom that change
> got made. For example the following commit message I'd consider quite
> useless (at least two or three years ago):
>
> "Add the one person one vote clause to GLEP 39 as agreed." [1]
>
> Who did agree? Where is that noted down? ... and so on.
>
>> An EAPI review committee could work well also. As long as we could get
>> non bias people in there.
>
> I was thinking about that for quite some time and as long as we get some
> non-biased people in there we should try that as well.
>
>> The council should be more about community vs technical issues only.
>> We have lots of top level projects within Gentoo which have simply given
>> up on the council as being an outlet to accomplish anything useful.
>> It should be our job to look at the projects in Gentoo. Look at the ones
>> that have a healthy community and encourage and promote them in ways.
>
> ack
>
>> For example prefix comes to mind. It was a project I did not like at
>> first. I'm not even a user. And there are things I surely don't like
>> about it as is. But there is community support and it's the icing on the
>> cake for some. So I'll back the fsck up and give credit where it's due.
>> This is a perfectly good example of a project/fork that needs to come
>> back home. Perhaps it's time to cherry pick some more stuff/people out
>> of Sunrise?
>
> prefix is a really good example, yeah. Nearly noone knows it, but it's
> really cool to have for example a virtualized windows machine running on
> a linux host. The windows box then runs prefix in interix. Not that it's
> really useful at all (hey, it's slow as hell) - but it's very
> interesting that such things are possible and it's definitively an
> eyecatcher on expos. prefix is one of Gentoo's most underrated projects.
>
> As for Sunrise I do think that's what we already do - but: getting users
> more actively involved in Sunrise makes them happy, plus it's easier for
> us to recruit new developers. Therefore: push Sunrise! I very much
> disliked how the Sunrise project has been started some years ago, but in
> the end we do need to integrate it a tad better to make it even more
> useful for both users and developers.
>
>> desultory points out any two council members can decide to approve anything,
>> and that decision is considered to be equivalent to a full council vote
>> until the next meeting. I vaguely recall that rule. I'm not sure about you,
>> but I think that is a little to much power to put in the hands of a few.
>> Any dev mind if we dump that power?
>
> It's quite much power in quite a few hands, but in the end that's some
> kind of "last resort rule". All council members should be smart enough
> (and i do consider all of us being smart enough) to know when that "last
> resort" becomes active. Therefore I think it doesn't hurt to have such a
> rule in place.
>
>> Meetings will likely go back to one time per month and be +m with +v be
>> handed out per request with open chat pre/post meetings.  The reason for
>> this is to keep the meetings on-track. I won't engage in endless
>> discussions. Facts can be presented. They will be reviewed on merit,
>> technical and social.
>>
>> The reason the meetings should go back to monthly is to allow those who
>> are council members in Gentoo to accomplish things other than the
>> council only. We all have personal lives and we all have our respective
>> roles we play outside of the council. Another note on meetings. The time
>> they are held currently don't fit well with my work schedule.
>
> I'm all for going back to monthly meetings and make them a tad more
> organized. As I summarized in the last few minutes of our last council
> meeting - we do have rules in place to keep our meetings organized, we
> just need to follow them.
>
> As for meeting times we can (that was mentioned somewhere?) move to 21
> or 22 utc - if we're going to monthly meetings and restrict meetings to
> say 60 or 90 minutes. If we have an agenda sent out a week ago everyone
> should be able to be well prepared for the meeting so a restriction on
> length of meetings wouldn't hurt.
>
> If council@g.o is updated we can quickly vote on meeting times.
>
>> Thank you all and I will try not to let you down. Unless you were one of
>> the ones who wanted to me lose. Then sorry, but I'm going to have fun
>> disappointing you, by doing what is best for Gentoo.
>
> And that's basically our job: taking care of Gentoo.
>
>> So lets have some damn fun again !@#$
>
> yay!
>
> - Tobias
>
>
> [1]
> http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0039.txt?r1=1.1&r2=1.2
>