On 06/05/2012 12:04 AM, inode0 wrote:
<snip>...</snip>
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.
Well, I have no objection with things being beneficial to RHEL. I
would argue that Fedora providing technology desired by RHEL and other
downstream consumers is as important for Fedora as anything else we do
that is motivated by a target audience.
Here we come to a point of one of what I consider a core issue in the
community which is this so called "target audience" and the set of
"Default" that goes with it.
From my point of view the board should not decided what is that so
called "target audience" or is the so called "Default" we ship but
rather we should allow each sub community to define it's own set of
target audience ( which afaik they do btw ), we drop the so called
default to give all sub communities and various components an equal foot
to stand on and equal presentation on our web site etc. and resources
within the project ( which currently is not the case ) because the
community is filled with components that provide same or similar function.
Arguably having the "Default" has been historically and will continue to
be the cause for the most confrontation within the project heck if I put
on my QA hat every release cycle we are faced with the question if we
should only test Gnome or if we should test Gnome and KDE ( due to
historic reasons it has been allowed to tag along ) or should we test
Gnome, KDE, XFCE,LXDE which we try to do to the best of our ability
since in essence we are an service in the project as is releng and
design community's as well but we are kinda being told to only test the
so called "Default" which btw no criteria exist for which leads to the
fact that none of the other *DE sub community's can strive to become
that "Default" to get the same treatment as we are giving the current
set of defaults ( see what I'm getting at with this)...
<snip>.. </snip>
I'm not that entirely convinced that Christoph being on the both sides of
the table in recent FamSCo event was a "positive" thing.
Both sides of what table? The Board had nothing to do with the
reorganization of FAmSCo as far as I know. Well, aside from ignoring
the call to disband FAmSCo. :)
Serving both sides of the tables is always a bad thing from my pov.
Arguably the process should be this.
You can run for any open position within the project if you aren't
already serving one
If you should get elected in more than one you will have to choose
which one you will serve and the next runner up will take the seat you
give up.
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.
Please. So few people vote if you could just get 100 people to vote
for candidate X that candidate would win. Hardly anyone from Red Hat
votes, hardly anyone from the community votes.
At least regardless of what that corporate is it should never be allowed
to hold majority of seats in any governing body within the community
from my pov
( Unless ofcourse these seats are being filled in by the FPL because of
lack of nominees )
<snip>...</snip>
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.
Yes, and in the case of the Board the rule is that the FPL appoints
all the seats that the community failed to field candidates for - bet
you don't like that rule.
Nope I actually agree with that rule very much and the FPL should
appoints whomever it feels like even fill all the seats with Red Hat
employees for all I care including people serving other governing
positions within the project.
In the other cases the elections are delayed hoping more candidates
will show up. Neither of these is a good thing.
It makes no sense delaying it.
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...
I just don't think this small thing is important. I doubt anyone
voting remembers anything from that introduction when they vote.
I personally read the pages always when the nomination period ends and
again before I cast my vote.
Certainly it isn't nearly as important as their contributions and
standing in the community. It isn't as important as their answers to
community posed questions. It is about the least important thing they
do in the election process. And the rules governing the introductions
are set by each governance body. The Board doesn't make anything more
than your name mandatory, FAmSCo has rejected nominations for not
filling out the information in the past.
I dont make distinction in those things like you do I take all of these
things into account and I consider each of those being of equal value
when doing so.
<snip>...</snip>
Townhall meetings are failures from my point of view due to various reasons.
They are failures from my point of view too, at least I see the
possibility for them to be far more informative than they are today.
But they will always fall short so long as contributors don't come and
participate in them.
I personally dont participate in things that I dont see working out.
JBG
--
marketing mailing list
marketing@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/marketing
