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 BF30E88A2 for ; Thu, 1 Sep 2011 19:59:29 +0000 (UTC) Received: (qmail 2426 invoked by uid 500); 1 Sep 2011 19:59:29 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 2384 invoked by uid 500); 1 Sep 2011 19:59:29 -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 2376 invoked by uid 99); 1 Sep 2011 19:59:29 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Sep 2011 19:59:29 +0000 Received: from localhost (HELO mail-ey0-f173.google.com) (127.0.0.1) (smtp-auth username robweir, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Sep 2011 19:59:28 +0000 Received: by eyb7 with SMTP id 7so2076990eyb.18 for ; Thu, 01 Sep 2011 12:59:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.16.86 with SMTP id g62mr68507eeg.128.1314907166908; Thu, 01 Sep 2011 12:59:26 -0700 (PDT) Received: by 10.14.188.2 with HTTP; Thu, 1 Sep 2011 12:59:26 -0700 (PDT) In-Reply-To: <4E5FE090.2020506@apache.org> References: <4E5FB6F0.2060504@ellisons.org.uk> <4E5FC756.5010106@ellisons.org.uk> <4E5FD55C.40207@ellisons.org.uk> <4E5FE090.2020506@apache.org> Date: Thu, 1 Sep 2011 15:59:26 -0400 Message-ID: Subject: Re: An invitation to committers to the OOo Community Forums From: Rob Weir To: ooo-dev@incubator.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Sep 1, 2011 at 3:44 PM, Terry Ellison wrote: > On 01/09/11 20:14, Rob Weir wrote: >> >> On Thu, Sep 1, 2011 at 2:56 PM, Terry Ellison >> wrote: >>> >>> OK, Rob, I now understand your point. =C2=A0I will do as you request. >>> =C2=A0However, >>> it seems to me that by making this request you are creating an >>> interesting >>> catch-22: =C2=A0I far as I can see there are two facets to this invitat= ion. >>> >>> =C2=A0* *Sufficiency*. =C2=A0These forums are closed because this gives= the >>> =C2=A0 =C2=A0attendees freedom to discuss matters (such as individual p= oster >>> =C2=A0 =C2=A0behaviour) that shouldn't be discussed on a public forum. = =C2=A0We only >>> =C2=A0 =C2=A0invite "trusted" forum members to join these lists. =C2=A0= (That's is >>> =C2=A0 =C2=A0that they've demonstrated that they are responsible and ha= ve built >>> =C2=A0 =C2=A0up a body of "karma" with their forum contributions.) =C2= =A0I would >>> =C2=A0 =C2=A0have thought that being elected a committer could reasonab= ly be >>> =C2=A0 =C2=A0deemed to be sufficient to show such trust. >>> >>> =C2=A0* *Necessity*. =C2=A0You seem to want to discuss policy on the go= vernance >>> =C2=A0 =C2=A0of the forums from within this DL or ooo-private. =C2=A0I = also recall >>> =C2=A0 =C2=A0some of your previous comments which indicate that these p= eople >>> =C2=A0 =C2=A0(who have committed hundreds if not thousands of hours to >>> =C2=A0 =C2=A0supporting this service) do not merit committer status unl= ess they >>> =C2=A0 =C2=A0have a wider engagement in the project, and they are there= fore >>> =C2=A0 =C2=A0excluded from any ooo-private discussions. =C2=A0Yet, it s= eems to me >>> =C2=A0 =C2=A0that it is entirely reasonable that anyone contributing to= this >>> =C2=A0 =C2=A0discussion should at least have a working knowledge of how= the >>> =C2=A0 =C2=A0forums operate in practice and currently govern themselves= . =C2=A0So I >>> =C2=A0 =C2=A0do think it necessary as well. >>> >> >> This is incorrect. We're obviously discussing the policy on the >> public list. We have not discussed this on ooo-private. Discussion >> of policy regarding the treatment of confidential information is >> itself not confidential. In fact, such discussions should probably >> always be public. >> >> You are also incorrect in your assumption that volunteers need to >> contribute in several areas in order to be committers. Someone who >> makes substantial contributions as a support forum moderator could >> make a great committer candidate. Ditto for a documentation writer, a >> tester, a translator, etc. Committers are not just coders. It is >> about commitment to the project. >> >> You are suggesting two problems: >> >> 1) We have forum moderators who understand how the forums work, but >> have not made visible contributions to the project yet, so they are >> not currently being nominated as committers. >> >> 2) We have committers who are not familiar with how the forum operates. >> >> And I'm raising the 3rd issue: >> >> 3) How the forum operates should not be something that occurs in private= . >> >> There is a clear solution here: >> >> 1) Have those who understand how the forum operates today write this >> up in detail as a contribution to the project's website >> >> 2) This would help other committers understand how this works and >> avoids the newbie problem you are concerned with, though we are >> probably not half as dumb as you seem to be assuming. I, for example, >> have run a phpBB board before. > > The issue isn't about phpBB, its more about we operate *these* forums. >> >> 3) This also gives the PPMC and Mentors an opportunity to review the >> forum procedures and ensure they conform Apache expectations, etc. >> This is something we should be doing anyways. >> >> 4) This effort, both in writing up the procedures, and educating the >> existing committers, and through this mutual discussion, would >> probably be a sufficient sign of commitment to get the moderators who >> are do this work to be nominated as project committers. >> >> So a win-win situation, all around. >> > Rob, I think that on your last comments we are lot closer than on your fi= rst > reply. =C2=A0However, we can either choose to make this change: > > A) a disruptive one: that is we lay down some (from the perspective of th= e > volunteers who are currently doing this work) arbitrary and seemly > irrational new rules on a love it or leave it basis. =C2=A0In my experien= ce many > or most will leave given this sort of diktat. =C2=A0It's a good way to ki= ll off a > service. > > B) an evolutionary one: that is we engage constructively and get to > understand the range of perspectives then move the service incrementally = to > an end-point that is mutually acceptable. > > In my experience many or most supporters will leave when faced with the (= A) > sort of diktat. (B) works a LOT better, especially when the people involv= ed > are making their commitments pro-bono. So I tend to feel that people who > start with (A) really have an agenda of shutting down a service and those > who start from (B) want it to prosper. > Transparency is not just a "nice to have" at Apache. Transparency is not irrational. Transparency is not something we slowly evolve towards in order to accommodate working habits of volunteers. Transparency is fundamental about how we do things. If operating transparently is seen as disruptive, then that may mean that we are doing a poor job as a PPMC at explaining the importance and value of transparency to our project participants. If you are concerned about embarrassing things in the existing legacy private forum contents, that is easy to deal with. We could simply expunge that data during the migration. We can start fresh. Could we get the forum moderators to participate in this discussion? It will be seen as a less of diktat they participate in this discussion directly. If they are not already on this list, I'd be glad to invite them, if you can point me to their addresses. -Rob > //Terry > >