My proposal for voing and such

[warren]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dearest Evilbob,

 We've just concluded a secret meeting about you (removes nazi-era
armband) and well.. in order to maintain our collective stranglehold
of disorganized "old boy" secret clique mentality on the bulk of the
Fedora IRC system you have 90 days to shape up or ship out. Hope this
helps!

Yours truly,

"Der Untergang"

On 01/22/2012 10:48 AM, Robert 'Bob' Jensen wrote:
>
> ----- "Kevin Fenzi" <kevin at scrye.com> wrote:
>
>> ok, here's my proposal, feel free to pick it apart, or use it as the
>> basis for your own different proposal. ;)
>>
>> a) The sig controls/manages the following channels:
>>
>> #fedora
>> #fedora-social
>> #fedora-unregistered
>> #fedora-ops
>>
>> b) Voting members are everyone who's an op in any of the managed
>> channels.
>>
>
> For general "ops" items I agree that "all ops from controlled channels
vote" but in other cases I disagree, Why should operators from
#fedora-grassroots be allowed to vote on a rule or new operator that
only applies to the #fedora and #fedora-social channels? After all
#fedora-grassroots has always allowed anyone that asked for ops to be an
op in that channel to be an op. It never has removed anyone that was an
operator for many years, their operator pool is now 50+ being able to
over ride all sanity for other channels.
>
>> c) New channel operators are added or removed with the following
>> process:
>>
>> 1. A ticket is filed with background/info and what channel the person
>> would like to be added to, or should be removed from.
>>
>
> I have always suggested that an existing operator take responsibility
for a user to gain potential op status. I still believe this is the best
case, with out this buffer we can and will be inundated with operator
requests so that we are either unable to get anything else done or will
be overwhelmed that we overlook good potential ops and also approve
those that may not have what it takes.
>
>> 2. A 7 day voting period begins.
>>
>> 3. At the end of 7 days votes are tallied and a simply majority
>> passes
>> or defeats the proposed add/remove.
>>
>
> 7 days is fair, many can't make it $sleep/family/employment or just
dislike our meeting format/procedure.
>
>> d) New channels can be added or current channels removed from
>> management via:
>>
>> 1. The current sig or group that controls a channel should ask to be
>> added in, or agree that they would like to be when approached.
>>
>
> I think the controlling sig has to be the ones that come to us rather
than just a single op for that channel. In other replies to the original
message "control" has been implied.
>
> How do we as the operators sig control a channel that has existing ops?
>
> Are they then grandfathered in to the sig?
>
> Are they voted in to the sig like other new ops and then given control
to the channel they have been part of?
>
> Are they bounced out on their butt?
>
> Do we have the man power to monitor these channels for regular monitor
these channels or are we just ops and available for a call for help?
>
> Do these new channels have to follow our SOP for dealing with trouble
and again do we have the man power to follow up on the, IMO, cumbersome
SOP we have developed?
>
>> 2. A vote is taken, if approved after the 7 day voting period, the
>> operators in the new channel all join the voting members pool and the
>> channel is added to the top list.
>>
>> e) In other cases (aside from promoting/removing members or
>> channels),
>> broad consensus should be attempted first and if no clear consensus
>> can
>> be reached a vote can be held on the issue or change.
>>
>> Feel free to pick it apart, add to or propose your own.
>>
>> kevin
>>
>> _______________________________________________
>> irc-support-sig mailing list
>> irc-support-sig at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/irc-support-sig
> _______________________________________________
> irc-support-sig mailing list
> irc-support-sig at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/irc-support-sig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAk8cZm0ACgkQI5ZhoGXYrD5nsgCdEClw81EPYUX3T7EyzvT3nOOB
2vwAnAmxIC08N2KuQ0V1JI8zi/FUyk7N
=9566
-----END PGP SIGNATURE-----