On 15.03.2013, at 22:16, Paul Davis <paul.joseph.da...@gmail.com> wrote:
> On Fri, Mar 15, 2013 at 3:13 PM, matt j. sorenson <m...@sorensonbros.net> > wrote: >> On Fri, Mar 15, 2013 at 2:39 PM, Paul Davis >> <paul.joseph.da...@gmail.com>wrote: >> >>> On Fri, Mar 15, 2013 at 10:54 AM, matt j. sorenson >>> <m...@sorensonbros.net> wrote: >>>> On Fri, Mar 15, 2013 at 7:16 AM, Noah Slater <nsla...@apache.org> wrote: >>>> >>>>> Hey folks, >>>>> >>>>> I'd like to bring two things to your attention: >>>>> >>>>> https://github.com/apache/couchdb/pull/43 >>>> >>>> >>>> ^ 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. > >> >>> >>>> >>>>> >>>>> https://github.com/cloudant-labs/couchdb/pull/18 >>>>> >>>>> 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 and >>>>> 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! >>>>> >>>>> [LINK TO MAILING LIST THREAD] >>>>> >>>>> == >>>>> >>>>> 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 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: >>> >>> http://www.apache.org/foundation/how-it-works.html#management >>> >>> 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] http://emjayess.net/think-like-jon-udell >>> >>> 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 > dev@couchdb.apache.org. 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. 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
