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
