My proposal for voing and such

[Kevin Fenzi]

On Sun, 22 Jan 2012 18:48:33 +0000 (UTC)
Robert 'Bob' Jensen <bob at fedoraunity.org> 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.

This would only be the case if #fedora-grassroots asked the SIG to
manage the channel, and it was approved in a vote. If they don't then
#fedora-grassroots does their own thing as they always have. Also,
#fedora-grassroots ops have no voting ability or special privs in the
SIG. 

Additonally, if #fedora-grassroots did ask to join the SIG, and was
accepted, then the SIG could use their normal processes to remove
inactive people or whatever. Or setup the inital ops list in
#fedora-grassroots some initial way. 

> 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.

Sure, I don't care if we require a nomination from an existing voting
member too much. I would prefer perhaps to see if we get a bunch of
requests tho. It may be a non problem... 

> 7 days is fair, many can't make it $sleep/family/employment or just
> dislike our meeting format/procedure.

yeah, it would exclude some people who are vacationing or whatever, but
life goes on. 

> 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. 

yes, we should state this explicitly. 

> How do we as the operators sig control a channel that has existing
> ops? 

To begin with, we only manage the 4 channels listed above. 
If we add a new channel, we should address that at the time. Either
replacing the existing ops or adding new ones or some combo. 
> 
> Are they then grandfathered in to the sig? 

I would think so. 

> Are they voted in to the sig like other new ops and then given
> control to the channel they have been part of? 

Thats another alternative.

> Are they bounced out on their butt? 

That too. 

Perhaps it could be on a case by case basis when adding new channels?

ie, #fedora-doom wants to join up. The sig is in agreement. 
They are fine with dropping all their ops that are currently in there
(many are not around anymore), but 5 people from the sig are active and
want to manage that channel and would like to be added. 

Then we vote on that? 

> 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?

I would say we should add specific folks to manage any new channels.

> 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? 

I would hope so. I would say almost no channels have the traffic and
issues that #fedora does. Any other channels should be much less work.

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/irc-support-sig/attachments/20120122/2bd739be/attachment.sig>