On 06/04/2012 07:03 PM, inode0 wrote:
On Mon, Jun 4, 2012 at 12:53 PM, "Jóhann B. Guðmundsson"
<johan...@gmail.com> 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.
JBG
--
marketing mailing list
marketing@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/marketing
