[CentOS-devel] Talk about existing forums

Akemi Yagi amyagi at gmail.com
Thu Dec 17 08:13:14 UTC 2009


Hi all,

Before the KB's message was posted to this mailing list, there was a
conversation among the people who participated in the chat. I am now
trying to paste the content of what we discussed in that conversation
for everyone to see.

Akemi

===============

On Tue, Dec 15, 2009 at 4:01 AM, Karanbir Singh <mail-lists at karan.org> wrote:
> Hi Guys, just following up with notes from the conversation :
>
> ===========
> Things that are good right now:
> - works
> - emerging community. ( 1200+ people have > 9 posts )
> - knowledge base
> - structure works well
 (snip)
> We need a Recruitment policy:
> - Step 1) Setup a document that lays out what would be 'criteria'
> - Step 2) Existing forum admins are able to nominate people
> - Step 3) People get accepted into the list-of-moderators
> - Step 4) Clear guidelines on how and when people leave
> =====================
> --
> Karanbir Singh

On 12/10/2009 09:36 AM, Akemi Yagi wrote:

Regarding Step 3, get accepted by whom and how?  I think it is
important to establish this procedure. In my not so humble opinion,
once a candidate is nominated by forum mods, the rest of the process
should be made semi-automatic (to say the extreme, even if that person
is unknown to core CentOS developers).

Akemi

================
Karanbir Singh wrote:

That could happen, being made semi-automatic, however we would need to
further lay down ground rules on criteria for such acceptance. And at
some level it would need to boil down to interaction and trust.

That could even come from a casual conversation, as an example.

The idea of trust channels and endorsements would come from the chain
its setup on. And it should really work end to end. It does in the
real world, so no reason why it cant work for us here as well - just a
case of working out how we would do it and then making sure everyone
is aware of it.

- KB

=================
Ned Slider wrote:

Of course, and that already seems to have happened a few times, Johnny
in recommending Akemi, Akemi then recommending me, and Akemi and
myself subsequently recommending Phil Schaffner.

>  That could even come from a casual conversation, as an example.

>  The idea of trust channels and endorsements would come from the chain its setup on. And it
>  should really work end to end. It does in the real world, so no reason why it cant work for us
>  here as well - just a case of working out how we would do it and then making sure everyone is
>  aware of it.

As I mentioned on the call, I have significant experience moderating
on much larger PC based forums than those of CentOS. One thing that
surprised me when I was first made a mod at CentOS was the all or
nothing level of control given out (maybe that is a factor of the
forum software). On other forums it is much more typical to grade
moderator roles (and thus privileges) which allows a person to be
introduced more gradually and thus allows trust to continue to be
built over time rather than immediately giving them the keys to the
kingdom. Obviously an initial level of trust is still there. Such a
hierarchical arrangement might look like:

Administrators - has full powers to perform administrative tasks, to
create and destroy subforums, ban users and IPs, to appoint other
staff. This might be one or more of the dev team

Super Moderators - have the power to ban users but not IPs (as this
should require root access), have the power to request an IP ban of an
admin and will review requests for IP bans from moderators, will
request the appointment of new moderators and supermoderators on the
basis of need (largely admins would rubber stamp these requests unless
serious concerns were raised), have powers to act in all areas of the
forum. Super moderators will also take a certain amount of
responsibility to mentor new moderators where required.

Moderators - might be appointed to a specific forum or areas to begin
with based upon experience. Forum mods have powers in their designated
areas/subforums only. They may edit/move/delete posts and temporarily
ban users in extreme circumstances (eg, a rampant spammer on the
loose), but permanent bans or requests of an IP ban must go through a
super moderator for discussion and implementation.

It's a very structured approach with everyone's role clearly defined.
No big decisions are ever taken in isolation and should generally be
discussed for a second opinion. Moderators are your day to day
workhorses within the forums, supermods are essentially middle
managers
responsible for overseeing the day to day actions of the moderators
and responsible to the administrator(s).

Currently we all immediately are granted powers somewhere between
supermod and admin level which implies a far greater trust level and
thus makes it very hard to recruit suitable new people thus placing a
far higher burden on existing moderators.

Hopefully the benefits of moving towards a more structured system are
obvious, and as the forum continues to grow, essential.

==================
Scott Robbins wrote:

>>>> - Step 3) People get accepted into the list-of-moderators
>>> Regarding Step 3, get accepted by whom and how?  I think it is
>>> important to establish this procedure. In my not so humble opinion,
>>> once a candidate is nominated by forum mods, the rest of the process
>>> should be made semi-automatic (to say the extreme, even if that person
>>> is unknown to core CentOS developers).
>>
>> That could happen, being made semi-automatic, however we would need to
>> further lay down ground rules on criteria for such acceptance. And at
>> some level it would need to boil down to interaction and trust.

Again, this reminds me of what was happening with Fedora forums, before
it was fixed.  The moderators are the ones dealing with it, and one
either trusts them or they shouldn't be moderators.  I really don't see
why anyone not actively involved with the forum should have any say one
way or another.  All it does is waste time and aggravate the moderators.

If you don't trust them to make the decision, then get other moderators.

I realize that I sound extreme here, but again, having experienced the
issues with Fedora forum, when the main admin was so difficult to reach
at times--and one can not predict the future and say, "Oh, you can
always reach one of us..." because stuff happens.

If Akemi san says, this one is good, what is core going to do?
What is the point of having to wait for them to say Ok?

This completely destroyed the old FreeBSD forums.  Several moderators
eventually disappeared due to attrition, and at the end, there were only
two, who couldn't appoint others.  The administor had
disappeared--finally, it turned out that he'd become ill, and although
some people actually tracked him down and had phone conversations with
him, nothing was ever done. Eventually, the two remaining moderators
gave up, and a new forum was started, and there was nothing but spam
remaining  At around that time, first a new forum was started, then the
FreeBSD project wound up creating their own.

With Fedora forums, fortunately, enough people held on until the change
was made, but the majority of us were reading to just say the heck with
it.

>> The idea of trust channels and endorsements would come from the chain
>> its setup on. And it should really work end to end. It does in the real
>> world, so no reason why it cant work for us here as well - just a case
>> of working out how we would do it and then making sure everyone is
>> aware of it.

As mentioned above, it doesn't always work in the real world.  The more
people involved in a decision, the longer it takes.   Witness how the
wiki lost Max Hetrick, whose nagios articles are perhaps the best
around.
>>
>
> As I mentioned on the call, I have significant experience moderating on
> much larger PC based forums than those of CentOS. One thing that
> surprised me when I was first made a mod at CentOS was the all or
> nothing level of control given out (maybe that is a factor of the forum
> software). On other forums it is much more typical to grade moderator
> roles (and thus privileges) which allows a person to be introduced more
> gradually and thus allows trust to continue to be built over time rather

On the Fedora forums, that is how it works.  There are three admins.
One is extremely techical, the other two have wonderful people skills.
Then, there are several, probably 10 or 11 community managers.  We (I'm
a CM) have most of the essential powers, but some limitations.

Lastly, there are members at large.  These are forum members who are
allowed into the staff lounge, take part in voting on banning members or
not, and make sure that we (the staff) remember that our purpose is to
serve the members, not to blindly enforce rules, some of which can be
too rigid.  Again, it's a much larger community, (one reason for the
large amount of staff---also making sure that there are people available
in most time zones.)

>
> Administrators - has full powers to perform administrative tasks, to
> create and destroy subforums, ban users and IPs, to appoint other staff.
> This might be one or more of the dev team
>

Are they available?  Are they there, or does a disruptive member go for
days before one of the dev team gets there?

Again, as devs are generally too busy for the forums, I fail to see the
point in having one of them in charge.  Suppose, for example, one gets
married in another country?   :)  During that time another is ill?

Meanwhile, the people actively involved in the forums are unable to do
anything.

Again, having been through this situation, watching it destroy one forum
and seeing another handicapped to the point where the people actually
doing something with the forum had to spend, quite literally, HOURS
daily, especially with such a relatively small forum, there's no reason
that those not involved with it should have any input one way or
another.

Sorry for the extremism here, but again, having, twice, seen the results
of doing it that way, and perhaps speaking as more of a CentOS outsider,
it seems to serve no purpose but make the forum admins' lives more
difficult and waste their (unpaid) time.


More information about the CentOS-devel mailing list