Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Reply-To: <dennis.hamilton@acm.org>
From: "Dennis E. Hamilton" <dennis.hamilton@acm.org>
To: <dev@cassandra.apache.org>
References: <CALdd-zh4j8y3Lb9kSrOV72CSVY1GtWBuWEhoQY1f00X4NYVj9A@mail.gmail.com> <CALznzY6L37YMtqadWHxnkE_oXmfrEPmA0zXUKa27bSZtu=gzHg@mail.gmail.com> <CAORswtw4o9wSEXrenvuuYnwFtNNf6kqBh40xto__z=KwN20ihw@mail.gmail.com>
In-Reply-To: <CAORswtw4o9wSEXrenvuuYnwFtNNf6kqBh40xto__z=KwN20ihw@mail.gmail.com>
Subject: RE: A proposal to move away from Jira-centric development
Date: Tue, 16 Aug 2016 09:24:36 -0700
Organization: NuovoDoc
Message-ID: <00bc01d1f7da$b0c53360$124f9a20$@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQDr5CwhL6Mz9pwhCvO06WY6VnLmdgF0NfRlAVhGBueiAYIOsA==
Content-Language: en-us
archived-at: Tue, 16 Aug 2016 16:24:57 -0000


> -----Original Message-----
> From: Eric Stevens [mailto:mightye@gmail.com]
> Sent: Tuesday, August 16, 2016 06:10
> To: dev@cassandra.apache.org
> Subject: Re: A proposal to move away from Jira-centric development
>=20
> I agree with Benedict that we really shouldn't be getting into a
> legalese
> debate on this subject, however "it didn't happen" has been brought up
> as a
> hammer in this conversation multiple times, and I think it's important
> that
> we put it to rest.  It's pretty clear cut that projects are free to
> disregard this advice.  "It didn't happen" is a motto, not a rule.
[orcmid]=20

<http://community.apache.org/apache-way/apache-project-maturity-model.htm=
l>

Please read them all, but especially the sections on Community, =
Consensus Building, and Independence.

Apache projects are expected to govern themselves, PMCs are responsible =
for it, and PMC Chairs (officers of the foundation) are accountable to =
the Board on how the project is striving toward maturity. =20

On occasion, deviations are so notable that there is objection.  It is =
not that folks run around policing the projects.  But there are =
occasions where there are concerns that a project has gone astray. =20

One maturity factor that might not be emphasized enough is =
Sustainability.  It is about the transparency of project conduct, the =
inclusiveness of operation and visibility, and the ways that growth and =
turnover are accommodated.  Since we are looking at mottos, "community =
over code" comes to mind. =20

Project freedom is a bit like the freedom to drive at 100mph on an =
arterial highway.  Occassionally, the infraction becomes worthy of =
attention and even a road block and spike strips.

While individual preferences are being discussed here, and I agree it is =
more pertinent than top-posting versus bottom-posting, what is lacking =
is a broad discussion on community.  Not incumbents and the =
karma-privileged, but the overall community and how one sustains a =
thriving project that strives for maturity.

Folks who are concerned about managing the mail stream and choosing what =
matters to them might want to discuss ways of operating lists in support =
of those concerns.  There are positions here and not enough questions =
about what might be workable inside of the practices and policies that =
are the waters Apache projects swim in.

 - Dennis
=20
>=20
> Per ASF newbie FAQ referenced by someone else earlier [1]:
>=20
> > The section on ASF Mottos is especially useful as a reminder of the
> way
> things are in most ASF projects. This section includes such gems as:
> > * Put community before code.
> > * Let they that do the work make the decisions.
> > * If it didn't happen on a mailing list, it didn't happen.
> > * Don't feed the trolls.
>=20
> This is presented as a general guideline and not a hard rule, and as
> Benedict points out even this is preceded by a guideline suggesting =
that
> developers are free to seek alternatives.
[orcmid]=20

The alternatives must fit within the overall principles, however.  Not =
deviate from or weaken them.  This is not an opening for arbitrary =
conduct.

If a major exception is required, it is up to the project to deliberate =
on the matter, agree on the desired exception and its justification, and =
take it to an appropriate venue for ratification. =20

(It is useful to keep in mind that exceptions are not precedents for =
others to cherry-pick.)

It is also the case that the PMC and, indeed the Chair (although =
consensus is always better), can set policies for the project.  They =
must be explicit and documented and available to all.

It would be really great to stop fighting city hall and, instead, start =
an inquiry into how the principles behind those practices are to be =
accomplished in the project's way of operating.

>=20
> Now since this is just a reference to the Incubator code of conduct's
> list
> of mottos (again, not ASF policy), which best source I could find [2],
> mirrors the newbie FAQ, but provides the additional insight that the
> objective of the motto is transparency.  The spirit of this motto is =
not
> meant to dictate a technology choice, but merely to indicate that
> discussions should happen in open spaces where all are able to
> participate.  The motto was authored in a time when "the lists" was =
the
> only real option.
>=20
> Jira absolutely meets the design goal of that motto, if that's the
> direction the community chooses, and it's clear from both sources that
> individual communities (they that do the work) are free to find the =
path
> here that's best for them.
>=20
> [1]
> https://community.apache.org/newbiefaq.html#NewbieFAQ-
> IsthereaCodeofConductforApacheprojects
> ?
> [2] *https://wiki.apache.org/incubator/CodeOfConduct#ASF_Mottos
> <https://wiki.apache.org/incubator/CodeOfConduct#ASF_Mottos>*
>=20
> On Tue, Aug 16, 2016 at 5:57 AM James Carman
> <james@carmanconsulting.com>
> wrote:
>=20
> > On Mon, Aug 15, 2016 at 10:23 AM Jonathan Ellis <jbellis@gmail.com>
> wrote:
> >
> > > A long time ago, I was a proponent of keeping most development
> > discussions
> > > on Jira, where tickets can be self contained and the threadless
> nature
> > > helps keep discussions from getting sidetracked.
> > >
> > > But Cassandra was a lot smaller then, and as we've grown it has
> become
> > > necessary to separate out the signal (discussions of new features
> and
> > major
> > > changes) from the noise of routine bug reports.
> > >
> > > I propose that we take advantage of the dev list to perform that
> > > separation.  Major new features and architectural improvements
> should be
> > > discussed first here, then when consensus on design is achieved,
> moved to
> > > Jira for implementation and review.
> > >
> > >
> > +1!  I think it's important to point out here that nobody is =
proposing
> that
> > folks have to send an email like:
> >
> > "I was thinking of naming my variable 'foo' here, what do you guys
> think?"
> >
> > However, discussions and decisions that have an impact on Cassandra
> and its
> > direction/architecture (not an all-inclusive list here and we should
> use
> > reason to decide) should happen on the mailing list.  The idea here =
is
> > inclusiveness.  We want everyone in the community to have a chance =
to
> > contribute to these discussions.
> >