Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: 80.244.253.218 is neither permitted
 nor denied by domain of jan@php.net)
References: 
 <CAPaJBx6xwZFz8F6jLZxBXQNi3V+hQ3waDPZPM5++R_Ov0SKynw@mail.gmail.com>
 <CAO1Qm-jwuveUL9-CHm+7Ss7H=t1OtqaoYtfZK68yde-zkk+VBA@mail.gmail.com>
 <CAJ_m3YC7snFFMMKr8cEovZ+=Q_EDjfewPXyV_uspmOo0FYXiwg@mail.gmail.com>
 <CAO1Qm-iCavfez_QPcLQ7zVA5HfEL6jKU0dLRzv+RigsW2jTBGg@mail.gmail.com>
 <CAJ_m3YDAjeywLdNyknA-SaF8t2MLKJj0botZpt7OS=UWS8tS-w@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: 
 <CAJ_m3YDAjeywLdNyknA-SaF8t2MLKJj0botZpt7OS=UWS8tS-w@mail.gmail.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <03FF95EB-0FFE-41F8-9E3E-7E1E1F201A68@php.net>
Cc: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
From: Jan Lehnardt <jan@php.net>
Subject: Re: Comments threads on Github
Date: Fri, 15 Mar 2013 22:38:44 +0100
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>


On 15.03.2013, at 22:16, Paul Davis <paul.joseph.davis@gmail.com> wrote:

> On Fri, Mar 15, 2013 at 3:13 PM, matt j. sorenson <matt@sorensonbros.net> w=
rote:
>> On Fri, Mar 15, 2013 at 2:39 PM, Paul Davis <paul.joseph.davis@gmail.com>=
wrote:
>>=20
>>> On Fri, Mar 15, 2013 at 10:54 AM, matt j. sorenson
>>> <matt@sorensonbros.net> wrote:
>>>> On Fri, Mar 15, 2013 at 7:16 AM, Noah Slater <nslater@apache.org> wrote=
:
>>>>=20
>>>>> Hey folks,
>>>>>=20
>>>>> I'd like to bring two things to your attention:
>>>>>=20
>>>>> https://github.com/apache/couchdb/pull/43
>>>>=20
>>>>=20
>>>> ^ I opened that one (obviously(?))
>>>=20
>>> I suppose if I take the time to click through to your user account and
>>> compare your name to the one used to send this email. Though not all
>>> GitHub accounts have a real name anyway so its not always apparent
>>> who's contributing something even if I do go out of my way to figure
>>> out who is who.
>>=20
>> nod. I use a nick... i use it quite consistently, and make no
>> attempt to hide behind it (link it to my real name whenever
>> and whereever possible), but acknowledge that it's far from
>> obvious sometimes, and that there's a lookup cost attached
>> to figuring it out. I don't really plan to "switch" tho.
>=20
> To be clear, I wasn't intending to ask you to change by any means. I
> was just trying to point out that I would have had no idea you were
> connected to that PR unless I first though "I wonder if he wrote
> that?" and then went and investigated the PR on my own initiative. And
> in your particular case I could have connected your GH user account to
> your email account this isn't true in all cases.
>=20
>>=20
>>>=20
>>>>=20
>>>>>=20
>>>>> https://github.com/cloudant-labs/couchdb/pull/18
>>>>>=20
>>>>> These just happen to be two pull requests I looked at today, there are=

>>>>> more.
>>>>>=20
>>>>> On the one hand, this is great. Obviously. Any sort of constructive
>>>>> activity happening around CouchDB is great.
>>>>=20
>>>> thank you!
>>>>=20
>>>>=20
>>>>>=20
>>>>> But on the other hand, this discussion is core development discussion,=

>>> and
>>>>> should be happening on the dev list where everybody can see it.
>>>>=20
>>>> I'm not sure where you get that PR#43 is core dev at all, plz clarify?
>>>=20
>>> Its a change to the source code repository.
>>=20
>> to documentation. a mere policy file. hardly "dev".
>=20
> Changing documentation, especially fundamental how-to-contribute docs
> is something that is a project decision and hence should follow
> established project guidelines which means being on the mailing list
> for everyone to see and voice an opinion if they have one. Or they can
> choose to ignore it. But the important point of passing through the
> mailing list is giving all interested parties the actual choice.
>=20
>>=20
>>>=20
>>>>=20
>>>>>=20
>>>>> (This is foundational stuff for an Apache project. Community building
>>>>> should be focused around the mailing lists.
>>>>=20
>>>>=20
>>>> (I've already made it known that I don't agree with this at all)
>>>>=20
>>>>=20
>>>>> I get that Github is useful for
>>>>> people, but we're not a Github project, so our activity should not be
>>>>> happening there.)
>>>>>=20
>>>>> I don't know what to suggest. Obviously, I think pull requests are
>>> great.
>>>>> And I think the forking model of Github is great, because it allows
>>> people
>>>>> to contribute more easily, and in a manner that suits them.
>>>>=20
>>>> PR#43, for anyone that may have skipped the description and comments
>>>> thread there (or who may have commented and then deleted the comment
>>>> in a rush of "OMG-i-made-a-PR-comment-instead-of-sending-to-the-ML"
>>>> ASF policy loyalty silliness) is precisely about surfacing the Apache
>>>> CouchDB
>>>> contribution policy in a "github-official" manner that will make it far=

>>>> more
>>>> obvious ***to githubbers*** in just the way githubbers have (or will)
>>> come
>>>> to expect!
>>>>=20
>>>> IOW, it aims to greatly aid the very challenge that this email rant is
>>>> about.
>>>>=20
>>>>=20
>>>>>=20
>>>>> But on the other hand, we shouldn't be having important development
>>>>> discussions in pull requests.
>>>>=20
>>>>=20
>>>> disagree, again.
>>>=20
>>> You can disagree all you want, but that doesn't mean the ASF is going
>>> to change one of their fundamental policies or that we as a project
>>> can start ignoring that policy.
>>>=20
>>>>=20
>>>>> The PR isn't even against the Apache CouchDB
>>>>> mirror. It's against a Cloudant fork! (So even less likely that folks
>>> are
>>>>> going to see it.)
>>>>>=20
>>>>> Perhaps one of the policies we could document is that discussion of pu=
ll
>>>>> requests must be brought to the list.
>>>>=20
>>>> Again, could be accomplished in the manner PR#43 describes(!)
>>>>=20
>>>>=20
>>>>>=20
>>>>> That is, if a PR comes in to the Apache Github mirror, then we make a
>>>>> polite comment on the PR that points them to the mailing list thread a=
nd
>>>>> asks them to participate in that forum, so the maximum amount of devs
>>> can
>>>>> see and contribute.
>>>>>=20
>>>>> We could also say that if you have a fork of CouchDB, and you're
>>> planning
>>>>> to contribute the work back to Apache CouchDB (as is the case with the=

>>>>> Cloudant fork) that you do the same with any PRs that are made to your=

>>>>> repos.
>>>>>=20
>>>>> A sample template comment could be as follows:
>>>>>=20
>>>>> =3D=3D
>>>>>=20
>>>>> Thank you for the pull request!
>>>>>=20
>>>>> This is a mirror of the Apache CouchDB project, so many of the
>>> committers
>>>>> do not monitor it for comments. Instead of discussing this pull reques=
t
>>>>> here, I have started a thread on the [developer mailing list] and I
>>> invite
>>>>> you to participate!
>>>>>=20
>>>>> [LINK TO MAILING LIST THREAD]
>>>>>=20
>>>>> =3D=3D
>>>>>=20
>>>>> Additionally, the mailing list thread, or the first reply to it, shoul=
d
>>> CC
>>>>> the original author.
>>>>>=20
>>>>> One alternative to this (which is a bit of a mess, I know) is to write=

>>>>> an integration that copies Github comments to the mailing list thread,=

>>> and
>>>>> mailing list posts to the PR. Not sure that would work with forks of t=
he
>>>>> main mirror, however.
>>>>>=20
>>>>> Thoughts? Flames?
>>>>=20
>>>> I'm speaking personally, and I know there are strong and varying
>>>> opinions on the subject among participants here.
>>>>=20
>>>> I also know the CouchDB PMC leads have a strong desire to spur
>>>> involvement in the project, and nothing dooms my personal desire
>>>> to work towards contributing than some ill-explained ass-backwards
>>>> 90's era bureaucratic mandate that EVERYTHING be facilitated over
>>>> the ML.
>>>=20
>>> While various ASF policies can be dense and difficult to understand at
>>> times, the mailing list policies are pretty straight forward.
>>> Regardless of your personal feelings on email and mailing lists in
>>> general, the fact is they are the single most widely deployed and
>>> widely compatible interfaces to push notifications in existence.
>>>=20
>>> To be a bit more specific on Noah's link:
>>>=20
>>> http://www.apache.org/foundation/how-it-works.html#management
>>>=20
>>> The fact is that Apache uses mailing lists for development. Any
>>> development discussion that is not on this mailing list did not happen
>>> as far as the project is concerned.
>>>=20
>>>> In fact it is due to that policy and general ASF-iness that keeps me
>>>> closer to the sidelines. This is a hobby, at best, for me at this time,=

>>>> and I already have no chance of keeping up with the ML activity.
>>>=20
>>> Its important to point out that having a mailing list centric
>>> communication channel does not require contributors to read all emails
>>> on the list. Its quite acceptable to subscribe and ignore every thread
>>> that you don't care about. Even developers will skim threads or even
>>> skip uninteresting ones all together.
>>>=20
>>>> I'd rather see the asf git become the archive mirror, quite frankly.
>>>> How many resources could the ASF preserve (or apply more
>>>> productively - development, conferences, promotion) by adopting
>>>> github infra formally (for starters).
>>>=20
>>> There are a lot of people that think this way and its been an opinion
>>> voiced on lots of mailing lists. Mostly by people that use GitHub.
>>> Suffice to say the ASF has roundly rejected this due to a long laundry
>>> list of reasons.
>>>=20
>>>> And i'm not some 19-yro kid who grew up always thinking of email
>>>> as irrelevant legacy tech, I've been doing this awhile myself.
>>>>=20
>>>> There's a lot to it. And, unsurprisingly, I don't care for essays in
>>> emails.
>>>> It's about the bazaar model. It's about signal-to-noise (for each
>>>> individual!).
>>>> It's about being able to subscribe to the topics you care about and not=

>>> have
>>>> to wade through the noise of the topics you don't care about, just to
>>> find
>>>> those topics you do care about (because at some point, the value prop
>>>> just isn't worth it anymore). It's about *thinking like the web* and
>>>> **observable work**[1].
>>>>=20
>>>> (is the ML observable? sure, in a sense, but barely)
>>>>=20
>>>> It's about all of that and a whole lot more.
>>>>=20
>>>>=20
>>>>> Thanks,
>>>>>=20
>>>>> --
>>>>> NS
>>>>=20
>>>>=20
>>>> feedback always welcome of course, and thx for listening
>>>> --
>>>> matt
>>>>=20
>>>> [1] http://emjayess.net/think-like-jon-udell
>>>=20
>>> I appreciate the desire to leverage the activity at GitHub and I think
>>> that's a goal that we should keep as a project but the thing we need
>>> to remember is that as awesome as GitHub is, there's definitely
>>> downsides to it as well.
>>>=20
>>> There are plenty of projects not on GitHub and as much I as love
>>> GitHub I understand its not right for every project. And for people
>>> that really insist that GitHub is a panacea, I'll refer you to
>>> Torvald's rather colorful refutation of that position.
>>=20
>> There's a lot here, so I'll just try to summarize my position
>> that I am not questioning the INTENDED EFFECTS of ASF
>> Policies, I'm merely pointing out that the ACTUAL EFFECT
>> does not appear to me to line up with the intent. That, to
>> me, would be cause for HUGE concern and evaluation.
>>=20
>> I'm quite aware of Torvald's rants re github, and his reasons
>> for staying off. I've also suffered through my share of github
>> PR nightmares. I know from personal experience that to avoid
>> backlash, don't /join #git on freenode and mention github.
>>=20
>> However, I'm also aware that the same person begot git to
>> usurp the prior patches-by-email workfow that was in place.
>=20
> I'd like to point out that Git was written as a tool to make
> patches-by-email easier, not to replace it.
>=20
>> Perhaps also consider ranking the goals of the CouchDB project,
>> as contrasted to the linux kernel project. Near as I can tell (from
>> Noah's and Jan's priorities) community building and being very
>> inviting to new contributors is a higher order value than is, say,
>> perfectly formed changesets from established reputable
>> committers as per the kernel project. Github is a bit lapse on the
>> latter, but excels magnificently on the former.
>=20
> I would say that the intent is to make contributions as easy as
> possible and to that end enabling the use of GitHub as a mode of
> contribution is definitely a priority. But the issue I think we're
> disagreeing on is where the primary source of truth flows. In our case
> as is the case for all Apache projects there is a very specific and
> basic rule that this source of truth is the dev@project mailing lists.
>=20
>> as someone who's basically just wandering in (or by?) I merely
>> wish to point out that there are some impedance mismatches
>> between what I see people describing as goals for the project
>> and the resulting or rather pre-existing ASF rigor. What I get
>> back is "this is what we've always done, so this is what we'll
>> always do", which is fine. But in my eyes, it's also a risk to the
>> "longevity and provenance" of couchdb, and since I HEART THE
>> HECK out of couchdb, that is concerning to me. Personally.
>=20
> I think the issue here is similar to one I've seen brought up during
> my time trying to get Git into general use at the ASF. There is a
> large group of people involved with the ASF that share your opinion of
> moving whole sale to GitHub. The idea of that move has been
> consistently and uniformly rejected by Apache's board for a variety of
> technical, social, and even legal reasons.
>=20
> I also don't accept your premise that contributing via GitHub is
> significantly more easy than writing an email to
> dev@couchdb.apache.org.

I don't accept that that is correct. If you are in the GH-flow (which has co=
st to entry) it is SIGNIFICANTLY easier than emailing. Maybe not the act of s=
ending a message after either workflow is set up, but everything else around=
 a pull request is a joy to use and none of email is.


> GitHub does have some nice tools sure but not
> everyone can or is willing to use them.

Neither of us have numbers, but I am willing to wager a made-up ratio of 90-=
10. As long as we do not actively exclude the 10%, there is no reason to mak=
e life easier for the 90.

Jan
--

>=20
>> And I apologize if I'm rocking the boat too much.
>=20
> No need to apologize. You're definitely not alone in your opinion. And
> I do want to apologize if I've come off a bit short in this
> conversation, its just one I've personally had many many times so I
> tend to forget what other people haven't seen or read.
>=20
> Plus if we couldn't stand someone wanting to discuss policies on
> contributions then we wouldn't be a very fun project to work on.
>=20
>> --
>> matt