couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Comments threads on Github
Date Fri, 15 Mar 2013 21:39:56 GMT


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

> Yeah, I'm not sure #3 would fly at the ASF. It might though but I was
> just trying to say that I would be surprised if we got an OK that it
> was an acceptable requirement for people to contribute to an ASF
> project.

Even with the caveat that we can post it there for them worst case like we already did with
JIRA issues at times?

Jan
--


> 
> On Fri, Mar 15, 2013 at 3:47 PM, Noah Slater <nslater@apache.org> wrote:
>> I see Paul's argument, but I don't think it's a blocker.
>> 
>> In my head, I imagined something like this:
>> 
>> 1. PR is opened
>> 2. ASF script sends notification to ML
>> 3. Someone spots it on the ML, goes to Github, posts a comment
>> 4. ASF script sends notification of that comment to the ML
>> 5. Original PR author responds
>> 6. ASF script sends notification of that comment to the ML
>> 7. etc...
>> 
>> Each interaction is happening on Github, and what we're seeing is a record
>> of activity on dev.
>> 
>> Compare this to how we work with JIRA.
>> 
>> Seems perfectly doable to me.
>> 
>> And so what if people have to sign up for a Github account? If they are
>> really so against it, post something to the list, and ask someone else to
>> forward on your message, or what have you. I really see no basis for
>> objection here.
>> 
>> 
>> 
>> 
>> On 15 March 2013 20:43, Jan Lehnardt <jan@apache.org> wrote:
>> 
>>> 
>>> On Mar 15, 2013, at 21:40 , Paul Davis <paul.joseph.davis@gmail.com>
>>> wrote:
>>> 
>>>> On Fri, Mar 15, 2013 at 3:05 PM, Noah Slater <nslater@apache.org> wrote:
>>>>> Github could be the best thing since sliced patches, but the ASF will
>>> never
>>>>> place it's primary data on a third party, because being self-sufficient
>>> and
>>>>> vendor neutral is one of the founding principals of the organisation.
>>>>> 
>>>>> This makes a lot of sense. Anyone remember Google Code? Remember how
>>>>> AWESOME Google Code was? I even had my website hosted out of it.
>>> Everyone
>>>>> was doing cool shit with Google Code. Because it was AWESOME. That
>>> wasn't
>>>>> that long ago, when you think about it. CouchDB was in a Google Code
>>> repos
>>>>> before we moved to Apache. But now who uses Google Code? I mean,
>>> seriously.
>>>>> When you see a project hosted on Google Code, doesn't your heart just
>>> sink
>>>>> a little bit?
>>>>> 
>>>>> The point being, can you imagine if the ASF had decided to move all of
>>>>> their hosting to Google Code? Can you imagine how embarrassing that
>>> would
>>>>> be now? Where would we be today in that world? Would we migrate again?
>>>>> 
>>>>> Github is awesome. And I enjoy using it. And there are many very
>>> successful
>>>>> projects who have formed a community around the workflows that it
>>> offers.
>>>>> (Hello Node.js people!) And that's awesome. Genuinely. But we are not
>>>>> hosted on Github, and our community is not a Github shape. BUT we
>>> should do
>>>>> everything we can to welcome contributions through that channel. Just
>>> like
>>>>> we should work to welcome communications through any channel. Git is
>>> meant
>>>>> to be decentralised, after all. ;)
>>>>> 
>>>>> Paul, to your points, Jan is chatting to infra about modifying our
>>> existing
>>>>> setup so that comments are sent through to the list as well. I am
>>> crossing
>>>>> my fingers that this is possible, and that it is reliable enough for
us
>>> to
>>>>> use. I am not sure how we're gonna get replies to be posted back, but
if
>>>>> there's an API, then I don't see why it can't be done.
>>>> 
>>>> Just to be clear, I think it'd be awesome if someone managed to get
>>>> this working. I'm just saying that I'm a bit pessimistic here. I think
>>>> we're agreeing here that getting email notices from GitHub PRs to the
>>>> dev@ list would be a good step but that getting mailing list updates
>>>> posted back to the PR is where the rubber meets the road. Without the
>>>> latter to close the loop there I don't see this as being anything more
>>>> than annoying to people attempting to contribute via PR as they won't
>>>> see updates from the list.
>>> 
>>> GitHub already allows emailing to Issues and PRs one is participating in.
>>> I’mma find out how we can make use of that.
>>> 
>>>> And I'd also point out that trying to have some sort of policy where
>>>> we tell people to sign up for a GitHub account to be able to
>>>> contribute to those discussions doesn't seem like a valid proposition
>>>> to me.
>>> 
>>> Excellent point. I was gonna suggest that we can live with a one-way
>>> sync for a transitional time, but this argument makes me reconsider.
>>> 
>>> Cheers
>>> Jan
>>> --
>>> 
>>> 
>>> 
>>> 
>>>> 
>>>>> If anyone wants to pitch in with this, please speak up. This would be
a
>>>>> great way to contribute to the Foundation. This script would likely be
>>> used
>>>>> by all of the Apache TLPs over time. Decent way to maybe earn some
>>> browny
>>>>> points too... ;)
>>>>> 
>>>>> 
>>>>> On 15 March 2013 19:39, Paul Davis <paul.joseph.davis@gmail.com>
wrote:
>>>>> 
>>>>>> 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:
>>>>>>> 
>>>>>>>> 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.
>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> 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.
>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> (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.
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> NS
>> 
>> 
>> --
>> NS

Mime
View raw message