couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: Comments threads on Github
Date Fri, 15 Mar 2013 21:44:41 GMT
We wouldn't be saying that you need a Github account to contribute to
CouchDB. In fact, you could post your comment to the mailing list. You
could post it via email to the original author. You could simply wait for
the PR to be merged in, and then veto the change, or what have you.

And I know this would fly, because it already IS flying. Right now, the way
Apache projects are set up is that people are commenting on PRs that are
done against forks on Github. And Infra know this, and the board knows this.

I have highlighted the problem with this. Namely, that these conversations
are becoming tiny ghettos. And I am actually proposing an *improvement* on
the status quo. That we allow these off-list conversations to happen
(because we can't stop them) and simply put a system in place so that we
expose them to the list for maximum visibility.

I think that's actually pretty critical. There's nothing we can do to stop
this. We can't set policy on Github. People are going to fork and comment
to their hearts content, for as long as there is something to fork from.

Emailing the copy of comments to the dev list is the way we turn this
potential negative into something positive.


On 15 March 2013 21:39, Jan Lehnardt <jan@apache.org> wrote:

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



-- 
NS

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message