From ooo-dev-return-4762-apmail-incubator-ooo-dev-archive=incubator.apache.org@incubator.apache.org Fri Sep 2 14:24:02 2011
Return-Path:
X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org
Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id 4713E7D3F
for ; Fri, 2 Sep 2011 14:24:02 +0000 (UTC)
Received: (qmail 1275 invoked by uid 500); 2 Sep 2011 14:24:02 -0000
Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org
Received: (qmail 1190 invoked by uid 500); 2 Sep 2011 14:24:01 -0000
Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: ooo-dev@incubator.apache.org
Delivered-To: mailing list ooo-dev@incubator.apache.org
Received: (qmail 1182 invoked by uid 99); 2 Sep 2011 14:24:01 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Sep 2011 14:24:01 +0000
X-ASF-Spam-Status: No, hits=1.8 required=5.0
tests=FROM_12LTRDOM,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [74.208.4.195] (HELO mout.perfora.net) (74.208.4.195)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Sep 2011 14:23:53 +0000
Received: from [9.33.93.147] (bi01pt1.ct.us.ibm.com [129.33.1.37])
by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis)
id 0Lx8qn-1REx8V3wD3-016Jc4; Fri, 02 Sep 2011 10:23:32 -0400
Message-ID: <4E60E6DF.6050006@shanecurcuru.org>
Date: Fri, 02 Sep 2011 10:23:27 -0400
From: Shane Curcuru
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Apache Way community moderation rationale
References: <4E5FB6F0.2060504@ellisons.org.uk> <4E5FC756.5010106@ellisons.org.uk> <4E5FD55C.40207@ellisons.org.uk> <4E5FE090.2020506@apache.org> <014801cc68e5$d5fd5290$81f7f7b0$@acm.org> <1314911707.1938.55.camel@sybil> <4E60193C.4090304@shanecurcuru.org> <4E606C19.40005@ellisons.org.uk>
In-Reply-To:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V02:K0:x6BLYM4GkooZ4H3k7sr4ncRm35oKvy8yJr37jhk2yAf
wGsI/H8h50bJf0fb9OEfwhezHQBm5PjlEHoZ5BwlPc3FIF2oaX
LxNiCvNZKV2TNJBAjlcqN7aE5cpISM2eDyM+LvalFW75xlqAmz
ZMLrueHcBwV+61lgQLUiFp69yXp7nRMqHWF0LBxb4fJ9z8HngI
nOzr9aHiBwcdcjiNxL7ASSKmdFVp1yooGoLcTL0XtxB40EvCBt
IGvIy+EbbP5AcDwGVGp7AX/Jyvdxd0XFFNsyq3OREvnFJAv4rK
ja2EGXFYrbj2Q4ZeJuQy1cMFmw2fAoPNguZoWYVHy9gFIS1GS2
hbvS9DT8H7DOHwN1DVXY=
A plea: it would be helpful, I think, to keep threads focused on
specific issues - either policy or technical.
There are some fundamental Apache Way issues on this thread I hope I can
shed some more light on, especially in terms of rationale.
-*- Public discussions/public mailing lists as relates to moderation.
A key reason that as much should happen on normal public mailing lists
is because that allows the community both to follow what's happening,
and also keeps the community involved in understanding appropriate
on-list (or on-forum, etc.) behavior. If you have a healthy community,
most trolls or disruptive posters will be told to go away/shape
up/whatever by community members, without requiring special moderators
or (P)PMC action.
Seeing this interchange on the list is a key way that other list
participants - and lurkers - can learn what the expected behavior on the
list is supposed to be. If the moderation decisions are done in
private, the rest of the community never sees what or how the
"appropriateness" is determined - they just see that some posters
suddenly disappear.
A crucial part of this is (P)PMC oversight, as well. If we don't have a
couple of PPMC members on the various admin-level forums, then we should
definitely get some.
-*- If it didn't happen on list, it didn't happen.
Two key points:
- Having decisions - and the discussion that forms them - on the list
ensures that all active contributors to the project see what was decided
and *why*. If they are reading the list regularly, they will have a
chance to participate and influence that decision. If they happen to be
on vacation, they at least will be able to see the discussions that
formed the decision, and can either learn from it, or can then form
their own cogent argument later for changing the decision.
Having basic discussions in person at a conference, on irc, or other
places is fine - as long as the content of the discussion comes back to
the list before a decision is made. Ensuring that the rest of the
community on the list can see participate is crucial.
- Oversight. Archived mailing lists at Apache are how (P)PMCs, Members,
ASF Officers, and the Board provide oversight for our projects. Thus,
project business must be on the list so that these people - some of whom
are not subscribed to the list - can still review the archives and
provide oversight and guidance.
----
NOTE: OOo is a huge project with a very diverse set of well-known
services, and, like, a LOT of users. To graduate to a top level project
will require significant changes to how some of these services are
provided in the future under any Apache marks or domain names.
Given the scale and breadth of services, and the changes in community, I
think it's appropriate to plan on plenty of time to make the complete
migrations of these services. Likewise, I believe it may be permissible
to take over hosting some services in the technical sense under the
openoffice.org domain - in the short term - that we might not normally
consider as managed fully by the Apache Way yet.
One way to think about services migration - to separate out policy
dependencies from technical ones - is:
- Ensure several PPMC members have root / admin / whatever level of
access is required to give them oversight, so they can review behavior
on the service. (first!)
- Technically port the service to apache hardware (but not under an
apache.org domain yet)
- Apply branding updates to the service
- Decide final policy issues for moderation, etc. for the service
Does that make sense? Given the past history and the fact that this
non-code content is not currently under an openoffice.org domain, it is
possible to technically migrate a lot of stuff without having finalized
the policy issues. (Note: source code and items under apache.org
domains are different, and should discuss policy issues sooner rather
than later)
- Shane