<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
<br>
<br>
- -------- Original Message --------<br>
Subject: Re: "Getting the ball rolling.."<br>
Date: Sat, 03 Dec 2011 11:13:38 -0800<br>
From: warren <a class="moz-txt-link-rfc2396E" href="mailto:warren@fedoraos.org"><warren@fedoraos.org></a><br>
Reply-To: <a class="moz-txt-link-abbreviated" href="mailto:warren@fedoraos.org">warren@fedoraos.org</a><br>
To: Kevin Fenzi <a class="moz-txt-link-rfc2396E" href="mailto:kevin@scrye.com"><kevin@scrye.com></a><br>
<br>
<br>
<br>
<br>
<br>
On 12/03/2011 10:23 AM, Kevin Fenzi wrote:<br>
<span style="white-space: pre;">> On Fri, 02 Dec 2011 19:24:15
-0800 warren <a class="moz-txt-link-rfc2396E" href="mailto:warren@fedoraos.org"><warren@fedoraos.org></a> <br>
> wrote:<br>
> <br>
>> <br>
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1<br>
>> <br>
>> Kevin,<br>
>> <br>
>> Here's where I'm currently at (and I will try to make
it as <br>
>> crystal clear as possible) before we even go any
further.<br>
>> <br>
>> 1. This is a large undertaking, not a one man task and<br>
>> definitely not something only I see. It's *going* to
ruffle<br>
>> feathers because things *will* change if this path is
taken. You<br>
>> know as well as I do that change is most often not well
accepted,<br>
>> regardless of intent or need.<br>
> <br>
> Agreed. People like status quo. Hopefully we can look
beyond that <br>
> though and see things that would help improve.<br>
> </span><br>
To me it's not about "hope" it's about coming to an agreement and<br>
deciding how it's *going to be* in fairness to *all* and moving<br>
towards that. "I fell and broke my front teeth, hopefully someday
it<br>
will be fixed, I'll just have to wait and see." No. You go to the<br>
dentist and get it fixed. You make a rule and it gets stuck to.<br>
Period, no exceptions. Otherwise there is no order and things<br>
deteriorate again. And I do not exclude myself from this either, I
and<br>
everyone else have the ability to decide how we're going to react
or<br>
act. I can apologize for acting a certain way but the fact remains<br>
that when I do or say something I chose to do it and I can just as<br>
well choose the opposite.<br>
<span style="white-space: pre;">>> I do however agree that
everything should be put to a vote, each <br>
>> item clearly stated, understood and voted for in a
peer-viewable <br>
>> and organized manner. i.e. not hidden, obfuscated or
obscured in <br>
>> any way.<br>
> <br>
> I'm not convinced voting is the way to go. I prefer
reaching some <br>
> kind of consensus with a rough majority. With voting you
get into: <br>
> Who can vote, how long do they need to consider items, what
items <br>
> can be put up for a vote by whom, should votes be public or
<br>
> private, etc.<br>
> <br>
> I would like to think that we could craft items such that
at least <br>
> a rough majority of people would see the advantage in doing
<br>
> them/switching to them.<br>
> </span><br>
I'm not sure what "some kind of consensus" is if it's not voting.<br>
Voting is a tally of consensus "should this guy be president?" yes
or<br>
no? A clear, fair system is possible and can be arranged without
too<br>
much effort.<br>
<span style="white-space: pre;">>> <br>
>> 2. You seem to be the only with with enough interest to
even <br>
>> reply,<br>
> <br>
> Well, give it time. Some folks are busy... I'd say we
should also <br>
> discuss this next week at the sig meeting as well. Perhaps
in IRC <br>
> some folks who can't be bothered to subscribe here would
chime in.<br>
> <br>
> </span><br>
waiting...<br>
<span style="white-space: pre;">>> save Thomasj who misread,
misinterpreted and simply fired back <br>
>> negatively based on who I am, and not the content or
context of <br>
>> the original email to this thread without the benefit
of doubt or<br>
>> clarification that he understood what he thought he
did. Granted,<br>
>> I should not have replied at all to him based on that
alone. It<br>
>> seems we were both ignorant and still have work to do.<br>
>> <br>
>> 3. There are some issues with both FedoraProject.org
and <br>
>> FedoraUnity.org pertaining directly to #fedora* IRC
channels <br>
>> (I'll be reading the links you sent me later this
evening, <br>
>> however I think I may have been the original author of
at least <br>
>> one of them although Sonar_Guy posted it on my behalf).<br>
> <br>
> Yes, you wrote up at least the initial version of what
became the <br>
> faq I think. :) Thanks!<br>
> </span><br>
Writing, thinking about solutions, noticing patterns and reactions
is<br>
what I feel I do best, including changing my own attitude and
personal<br>
patterns. I'm happy to drop old nonsense, move on and focus on
things<br>
that matter and affect the situation positively. It may be hard to<br>
imagine, but anyone is capable of anything they put their mind and<br>
focus on.<br>
<span style="white-space: pre;">>> a. FedoraProject - Who is
in control of #fedora* it's policies, <br>
>> procedures and direction?<br>
> <br>
> My understanding (and hopefully someone will correct me if
I am <br>
> wrong) is that #fedora* on freenode is a official "group".
meaning <br>
> the policies at:
<a class="moz-txt-link-freetext" href="http://freenode.net/group_registration.shtml">http://freenode.net/group_registration.shtml</a> <br>
> Apply. So, ultimately, the Fedora group contact has
control. In <br>
> practice I think the Board would be the ultimate aribiter
and they <br>
> seem quite happy to allow this SIG to organize and setup
policies <br>
> and process for #fedora as they see fit. For other #fedora*
<br>
> channels, such policies (if any) are governed by the
operators for <br>
> those channels.<br>
> </span><br>
Great, I'm not sure if there's an arbitration or dispute
resolution<br>
mechanism in place as well but that might also need some<br>
consideration, not only for my own situation but for those that
others<br>
face as well. Sweeping things under the carpet is bad practice and<br>
shows a certain lack of responsibility in my mind. Anyone in a<br>
position of power should be able to be trusted to make rational
and<br>
clear decisions without letting snap reactions and judgments cloud<br>
things.<br>
<span style="white-space: pre;">>> b. FedoraUnity - Sadly,
this project/group has never been well <br>
>> organized in any sane or official fashion, has only one
person in<br>
>> control of the domains / structure & organization
of content /<br>
>> top-level website CMS configuration which has caused
friction <br>
>> between many (who I will not name but let them make
their own <br>
>> statements), is not an official part of the
FedoraProject and <br>
>> therefore can do "whatever" without any direct
oversight or <br>
>> consequence by the FedoraProject. I've heard before on
multiple <br>
>> occasions "No one can make any top level changes
because it's <br>
>> been so highly customized none of us even know where to
begin." <br>
>> Which I've seen myself having paid the hosting bill for
a few <br>
>> years and helping manage aspects of the Zope/Plone
website which <br>
>> is now horribly out of date.<br>
> <br>
> I think this is beyond the scope of this list/group.</span><br>
<br>
This again to me is sidestepping the issue and avoiding the
obvious<br>
distaste you'll receive from others involved and with power at
stake.<br>
This issue is certainly part of it because these help resources
are<br>
continually referenced in #fedora, so yes, very relevant. Again I
have<br>
ideas for solutions to this however, I don't want to put time or<br>
energy into something that will ultimately go nowhere.<br>
<br>
<br>
<span style="white-space: pre;">>> 4. The "good ol' boy"
club attitude, looking the other way at bad<br>
>> behavior simply based on who offender is, what feet
might be <br>
>> stepped on, who might be offended, etc rather than the
actual <br>
>> behavior itself and whether it's acceptable. People
concerned <br>
>> with maintaining power, driving the direction of things
or <br>
>> stunting changes simply to control them have
questionable <br>
>> intentions in my opinion. It should not matter if it's
a channel <br>
>> op or someone who's just come in for the first time.<br>
> <br>
> Yes, agreed.<br>
> <br>
>> 5. Anyone not currently active on such a regular basis
as <br>
>> required by the task they are in control of should be
required<br>
>> to hand over the reigns to someone who is active and
qualified<br>
>> for the task. You don't take on tasks or
responsibilities that <br>
>> require ongoing attention then neglect or abandon them
and <br>
>> perform them whenever it suits your fancy. This goes
for<br>
>> everyone from ops to website maintainers, program
coordinators,<br>
>> etc, really any job that requires regular attention.
This is how <br>
>> things fall this badly into disrepair in the first
place.<br>
> <br>
> Also agreed, however: This is a volunteer group. Peoples
time <br>
> commitment varies as their other dayjob or life presses in.
Also, <br>
> some tasks are not easy to define. To be an operator should<br>
> someone police the channel for 20 hours a week? 5? 1?
10min? And<br>
> would they 'clock in' or how do you keep track?<br>
> <br>
> If you are unable to help out in the channel at all for 2
weeks, <br>
> but then can help out a lot the next, should you have been<br>
> removed?<br>
> <br>
> <br>
> I think this sort of thing works much more when there are
specific <br>
> deliverables: You must send a TPS report every friday or we
fire <br>
> you. Instead of: you must help out as much as you are able
to.<br>
> </span><br>
It is indeed volunteer, and before making such commitments it's up
to<br>
the volunteer to accept full responsibility for any such
commitments<br>
before accepting them. Making excuses about other obligations
might<br>
work in an emergency situation, but not as a regular thing. That's
a<br>
pattern and one that gets the entire project into disrepair if
allowed<br>
to grow or become passively accepted. And again, problems are only<br>
solutions waiting to happen, not excuses waiting to happen. All of<br>
this can be sorted out with enough initiative and thought. I don't
get<br>
too specific yet, because as I already stated, if no one cares,
I'm<br>
not going to count grains of sand at the beach to determine how
many<br>
we have.<br>
<span style="white-space: pre;">>> 6. As for dealing with
users posting outdated, false, misleading <br>
>> or outright bad info, this is why I propose a unified
help front <br>
>> that is 100% in control of the FedoraProject. Sending
people to <br>
>> the FedoraProject Wiki for one thing, FedoraSolved for
another, <br>
>> FedoraForum for yet another.. It's confusing and shows
<br>
>> discontinuity to the new and existing users whether
they realize <br>
>> it consciously or subconsciously. If there was a
unified front <br>
>> and the channel policy was only to send people to these
help <br>
>> resources it would flow much more smoothly. Please see<br>
>> #wordpress wordpress.org and/or talk to Freenode IRC
operator<br>
>> Sivel for examples on how this might be accomplished.<br>
> <br>
> Well, I think this is again good in principal... but what
if there <br>
> is a great other resource not on those sites that would
really<br>
> help the user? Ignore it and tell them we have no info?<br>
> </span><br>
If there's another great resource, then we set up guidelines that
are<br>
followed for what is an acceptable resource such as compiling from<br>
source, downloading random or incorrect rpms, suggesting that
SELinux<br>
be disabled, turning off iptables.. etc. These are some common<br>
well-known things among the experienced and simply suggestions for<br>
such guidelines. After something passes these guidelines it can
then<br>
be created, edited and formatted for inclusion in official help<br>
resources in a "work-flow" type scenario. There's clearly enough<br>
people in the community to make this happen with relative ease
once a<br>
system is developed and in place.<br>
<span style="white-space: pre;">>> Again, I have lots of
valid ideas and possible solutions for<br>
>> much of the above but yelling in an empty auditorium
won't get<br>
>> anyone anywhere. If Fedora is to be the "best" in its
product<br>
>> offering, support and general appeal then the work to
this end<br>
>> never stops. The above items are clear indications to
me and<br>
>> others in the community where change is badly needed.
It's<br>
>> certainly possible, the only real question is if anyone
else is<br>
>> willing to do the heavy lifting.<br>
> <br>
> Sure, lets see if others chime in...</span><br>
Let's.<br>
<span style="white-space: pre;">> <br>
> kevin</span><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.14 (GNU/Linux)<br>
<br>
iEYEARECAAYFAk7adUcACgkQI5ZhoGXYrD6BPQCeJdJEOqHIm6jZiVyWZoNhi4Xy<br>
zVAAn2F0TjDu28PRsSVcy5uQjOIaHtbb<br>
=eUPe<br>
-----END PGP SIGNATURE-----<br>
<br>
</body>
</html>