You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@openoffice.apache.org by Shane Curcuru <as...@shanecurcuru.org> on 2011/09/02 16:23:27 UTC

Apache Way community moderation rationale

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