couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Comments threads on Github
Date Fri, 15 Mar 2013 21:38:44 GMT

On 15.03.2013, at 22:16, Paul Davis <> wrote:

> On Fri, Mar 15, 2013 at 3:13 PM, matt j. sorenson <> wrote:
>> On Fri, Mar 15, 2013 at 2:39 PM, Paul Davis <>wrote:
>>> On Fri, Mar 15, 2013 at 10:54 AM, matt j. sorenson
>>> <> wrote:
>>>> On Fri, Mar 15, 2013 at 7:16 AM, Noah Slater <> wrote:
>>>>> Hey folks,
>>>>> I'd like to bring two things to your attention:
>>>> ^ I opened that one (obviously(?))
>>> 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.
>> 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.
> 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.
>>>>> These just happen to be two pull requests I looked at today, there are
>>>>> more.
>>>>> On the one hand, this is great. Obviously. Any sort of constructive
>>>>> activity happening around CouchDB is great.
>>>> thank you!
>>>>> But on the other hand, this discussion is core development discussion,
>>> and
>>>>> should be happening on the dev list where everybody can see it.
>>>> I'm not sure where you get that PR#43 is core dev at all, plz clarify?
>>> Its a change to the source code repository.
>> to documentation. a mere policy file. hardly "dev".
> 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.
>>>>> (This is foundational stuff for an Apache project. Community building
>>>>> should be focused around the mailing lists.
>>>> (I've already made it known that I don't agree with this at all)
>>>>> I get that Github is useful for
>>>>> people, but we're not a Github project, so our activity should not be
>>>>> happening there.)
>>>>> 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.
>>>> 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!
>>>> IOW, it aims to greatly aid the very challenge that this email rant is
>>>> about.
>>>>> But on the other hand, we shouldn't be having important development
>>>>> discussions in pull requests.
>>>> disagree, again.
>>> 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.
>>>>> 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.)
>>>>> Perhaps one of the policies we could document is that discussion of pull
>>>>> requests must be brought to the list.
>>>> Again, could be accomplished in the manner PR#43 describes(!)
>>>>> 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
>>>>> asks them to participate in that forum, so the maximum amount of devs
>>> can
>>>>> see and contribute.
>>>>> 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.
>>>>> A sample template comment could be as follows:
>>>>> ==
>>>>> Thank you for the pull request!
>>>>> 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 request
>>>>> here, I have started a thread on the [developer mailing list] and I
>>> invite
>>>>> you to participate!
>>>>> ==
>>>>> Additionally, the mailing list thread, or the first reply to it, should
>>> CC
>>>>> the original author.
>>>>> 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
>>>>> main mirror, however.
>>>>> Thoughts? Flames?
>>>> I'm speaking personally, and I know there are strong and varying
>>>> opinions on the subject among participants here.
>>>> 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.
>>> 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.
>>> To be a bit more specific on Noah's link:
>>> 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.
>>>> 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.
>>> 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.
>>>> 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).
>>> 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.
>>>> 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.
>>>> 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].
>>>> (is the ML observable? sure, in a sense, but barely)
>>>> It's about all of that and a whole lot more.
>>>>> Thanks,
>>>>> --
>>>>> NS
>>>> feedback always welcome of course, and thx for listening
>>>> --
>>>> matt
>>>> [1]
>>> 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.
>>> 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.
>> 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.
>> 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.
>> However, I'm also aware that the same person begot git to
>> usurp the prior patches-by-email workfow that was in place.
> I'd like to point out that Git was written as a tool to make
> patches-by-email easier, not to replace it.
>> 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.
> 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.
>> 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.
> 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.
> I also don't accept your premise that contributing via GitHub is
> significantly more easy than writing an email to

I don't accept that that is correct. If you are in the GH-flow (which has cost to entry) it
is SIGNIFICANTLY easier than emailing. Maybe not the act of sending 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 make life easier for the 90.


>> And I apologize if I'm rocking the boat too much.
> 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.
> 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.
>> --
>> matt

View raw message