On Thu, Jul 2, 2009 at 7:54 AM, Tobias Scherbaum<dertobi...@gentoo.org> 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 coun...@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 >
