Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of joant@lrtw.org designates
 204.11.51.157 as permitted sender)
Date: Mon, 26 May 2014 17:01:34 -0400 (EDT)
From: Joan Touzet <joant@lrtw.org>
To: dev@couchdb.apache.org
Message-ID: <10316916.565.1401138090904.JavaMail.Joan@RITA>
In-Reply-To: <39B52E61-8C43-4ECD-95D2-E6634A4CC62A@apache.org>
Subject: Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project
 bylaws)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On the "COPDOC" thing:

> > On 20 May 2014 23:43, Jan Lehnardt <jan@apache.org> wrote:
> >> 2.3. would specifically invite designers, both visual and user interfa=
ce designers. Not sure we need a name like COPDOC.
> >=20
> > I started down this path of listing things we're interested in, but it
> > got too long, so I spun it off into a new doc.
> >=20
> > https://cwiki.apache.org/confluence/display/COUCHDB/Contributor+Guide
>=20
> That=E2=80=99s good, but still lacking e.g. designers. The bylaws should =
include a summary, and/or a pointer to the=20
> Contributor Guide.
> > The COPDOC stuff has prior art:
> >=20
> > https://forrest.apache.org/committed.html
>=20
> I=E2=80=99m hearing this for the first time, I=E2=80=99d be afraid to sou=
nd overly complicated for no good reason and it=20
> doesn=E2=80=99t include some groups of folks that we (should) care about.=
 =E2=80=9CPeople that we care about contributing to=20
> CouchDB=E2=80=9D doesn=E2=80=99t need an acronym to make any clearer what=
 we mean.

I hadn't heard the acronym previously, and a quick web search doesn't turn =
up any other uses of it. Still, the list of "what we value," just like the =
list of "we don't discriminate against these things" should be ever-expandi=
ng. I am not opposed to spinning this lit out and instead saying something =
like:

  "We value contributions that include, but are not limited to: community, =
project, documentation, code, visual design, internationalisation, ..." and=
 then link to the contributor guide as a full resource.

My rule of thumb for something like bylaws is: if we have to change the byl=
aws ever, we made a mistake. That should happen every year or two *max*. If=
 something is liable to change often, spin it out into another policy doc a=
nd go from there.