On 06/04/2012 07:03 PM, inode0 wrote: > On Mon, Jun 4, 2012 at 12:53 PM, "Jóhann B. Guðmundsson" > <johannbg@gmai...> wrote: >> On 06/04/2012 02:51 PM, Paul W. Frields wrote: >>> This is a good explanation. I'd also reiterate that "against the >>> community" is not supported by the fact that (1), and (2) the FPL >>> >>> continues to appoint quite a few non-Red Hat employees, over the >>> Board's history. >> >> Well the FPL is not elected by the community but is hired by Red Hat through >> some internal process they have that we ( the community ) know nothing about >> and Red Hat has a track record of inventing position within the community >> then more often then not hire people outside the community to fill those >> positions. ( Even thou the company has been getting better at rephrasing >> these job positions and choosing people within the community rather than >> outside in more recent times). >> >> Arguably an better approach to choose an FPL is for the community to >> nominate individuals which then would be subjected to whatever process Red >> Hat uses internally to filter out and eventually get on it's payroll. > Arguably that is a worse approach too.
What are the downside you see to this approach?
>> At least to me that's the only compromising solution that I can see working >> between both parties involved without one ruling over the other. > I think you give the FPL more power than the position really has now. > While the position has great responsibilities both to the Fedora > community and to Red Hat, aside from the unused veto power over Board > decisions the FPL's "power" comes from doing good work and persuading > others by argument and more often by example that something is > valuable. Without community buy-in I don't see much power there.
This is about transparency, community's participation and independence in the process in choosing our own leader instead of having it chosen *for* us.
> >> With regards to "the Fedora community has chosen to elect quite a few Red >> Hat employees" which I can certainly agree to since I my self have voted Red >> Hat employees over community candidates since I base my voting more on the >> individual work and technical knowledge rather than on some popularity >> contest. >> >> But I still think that this is one thing that is wrong with our election >> process as in I feel that corporate entity's or individual from there in may >> not be allowed to hold majority of seats neither on the board nor in any of >> the committees within the community to prevent that corporates interest >> influence either directly or indirectly the projects direction and resources >> and that view of mine is not limited to Red Hat but to all sponsor, >> sponsoring the project ( if and then when Red Hat *decides* some other >> corporate can sponsor the project). > Don't you think the power to influence the project's direction is > coming from the work being done more than from participation on a > governance body?
Not with regards to FESCO no I cant say I can.
More often than not decisions that have been made there appear to me being more beneficial to RHEL than it actually does the project even more so do the action of FPC.
>> And here are few I think is wrong with election process and is needed to >> ensure fairness through out the community >> >> 1. >> The same election process should be used through out the whole project so >> famsco/fesco should follow the same process as do everyone else. > I'm not sure what you mean here. The process is almost identical for > FAmSCo and FESCo with minor details that differ like FAmSCo does not > require members to be in the packager group. :) > > I am interested in understanding what you mean though as I am also > very interested in an election process that the community believes in. > So please tell us in more detail where you think the problem lies now > in this case.
Look at fairly reason events in FamSCO...
>> 2. >> Individual may not serve on more then one committee at a time. > This one I have pretty strong sympathy for since in general I think > participating in multiple governance bodies tends to have more > negative consequences than positive. But there are always exceptions > and off the top of my head today the only person falling into this > category now is a volunteer community member elected to two of them. > And as far as I can tell he is doing a fine job on both.
I'm not that entirely convinced that Christoph being on the both sides of the table in recent FamSCo event was a "positive" thing.
>> 3. >> There needs to be a limit on how many release cycles or "terms" individuals >> may serve on the board/committees to ensure rotation and enough "fresh" >> ideas/approaches to any given task at hand. > I have some sympathy for this too. Getting new ideas into the > governance/steering discussion is a positive thing from my > perspective. Each governance body can choose now to create such > limits, has discussed them in the past, and seems to have always > rejected them. I think the usual arguments against imposing limits are > (1) voters can enforce any limits they choose by their actions voting > and
Not when there is a whole corporation voting for their *coworkers* in the elections which they either do so because of their own free will or because their manager might have put them up to it.
I know for a fact after being responded by one maintainer in the project who's name I'll leave out for his own sake that he could not update his package until his *manager* gave him permission to do so.
If you need another example which is publicly available in the projects archives is when an Red Hat employee proposed that all conflicts between Red Hat employee and community members would be handled internally with the relevant persons manager.
Fortunately I manage to attend the meeting share my views on that subject and the discrimination that would take place both against the Red Hat employees and the community in whole if that proposal would have been approved.
> (2) there have been periods where even getting enough people to > run to hold an election has been challenging without telling others > they can't run.
There already exist an rule to deal with that should that be the case which just needs to be extended to all governing body's within the project.
> > I'll point out that this is one place where the history of the FPL > might help inform the governance bodies of the value of new ideas and > fresh enthusiasm. > >> 4. >> Nominees cant change their "Introduction" once the nomination period has >> ended. > This is something we could just do. I'm not sure I see very much value > in doing it though.
This prevents people from altering their introduction, mission statements etc after the nomination period has ended and if people really have not bothered to take the time to properly fill these out before the nomination period has ended they should be disqualified from the election.
Ask you self these do we really want persons in a governing body that cant even do that simple thing?
To me this is pure common sense...
> >> 5. >> Nominees that seek re-elections should clearly state what work they did when >> serving their last election period. > Did you ask them to do that on the questionnaire or at a townhall? We > can ask the candidates whatever we want to ask them, someone just has > to take a few minutes and ask the question.
Townhall meetings are failures from my point of view due to various reasons.