couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Comments threads on Github
Date Fri, 15 Mar 2013 22:24:24 GMT
On Fri, Mar 15, 2013 at 4:38 PM, Jan Lehnardt <> wrote:
> 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 <>
>>>>>> 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
>>>>>> 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
>>>>>> 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
>>>>>> 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
>>>> 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
>>>>>> Cloudant fork) that you do the same with any PRs that are made to
>>>>>> 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
>>>> invite
>>>>>> you to participate!
>>>>>> ==
>>>>>> Additionally, the mailing list thread, or the first reply to it,
>>>> CC
>>>>>> the original author.
>>>>>> One alternative to this (which is a bit of a mess, I know) is to
>>>>>> 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 the
>>>>>> 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.

I think there's a significant assumption that you need to be willing
(and able) to adopt all of the workflow to use it though. I personally
detest what their workflow does to project history. I have to suffer
through it at work and I also happen to have just spent ten days
dealing with the specific effects of this workflow on history so I
might be a bit more bitter about merges than usual, but zomg I wish I
could destroy that goddamned merge button on PRs.

>> 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.

I'd have to do more thorough research to try and give you numbers on
developers per capita and then figure out what that is as a total
number of developers in the world. Suffice to say I'm guessing "not
insignificant" would be an understatement.

Either way, I don't mean to say that GH is terrible for everyone, I'm
just pointing out that its not awesome for everyone and its easy to
lose sight of that. I'm personally fine with enabling as much
collaboration via GH as possible but its important to understand that
on multiple fronts it is not and can not be the central hub of
development for an Apache project.

> Jan
> --
>>> 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