couchdb-dev mailing list archives

I think one or both of us is misunderstanding the other. First I'll
stop and write up my internal understanding of the current policy so
that we can hopefully compare notes more directly.
First, the ASF has a pretty specific policy on using the project
mailing lists to coordinate project activity as witnessed by the
rather hyperbolic, "If was written down on the mailing list, it never
happend". Obviously that's a bit of an extreme phrase intended to get
people to think about where they're actually doing development. It
doesn't mean you can't chat in IRC or discuss things over a beer or
ever talk about an Apache project out loud.
The point is that if someone wants to contribute or just follow
development of an Apache project there is a single place to look and
that is the dev@project.apache.org mailing list. There are a number of
social and technical issues that have reinforced this policy over time
such as the asynchronous nature as well as ease of use and minimal bar
to entry.
Its important to note here that this isn't just a technical policy
either. It isn't a "if we have a copy of everything sent to dev@ then
we're fine" thing we can (or in my opinion should) try and loop-hole
our way out of.
There's a much larger social issue here that is just as much about
perception as it is about the technical side of things and that's that
people need to understand that this is where the Discussion happens.
If we can loop in GitHub so that conversations over there are relayed
into this forum then that is (to me at least) following suit with the
social aspect of the policy. On the other hand, simply mirroring
discussions happening over at GitHub to the mailing list is *not*
compatible and should be avoided.
To me this social part is where the GitHub breaks down. We need to
make sure that when we go to start a conversation that we reach for an
email client and not GitHub's website. While its easy to just say
"because that's the way it is at Apache" the reason is that there are
real people in this world that don't necessarily have the ability or
the desire to use GitHub. Email is a much more basic tool with a much
lower barrier to entry.
A couple points in direct response to your email though. First, I'm
confused that you're citing Travis CI or ReadTheDocs in this
discussion as neither of those are forums for discussion. Tools are
tools. Hopefully I've managed to dissuade you from thinking that I'm
arguing that every tool needs to have an email interface. I'm pretty
sure that was a joke but I think clouds the larger point quite a bit
so I figured I'd be specific on it.
The core bit of your argument here is explicitly what I'm trying to
address by talking about the social implications of our mailing list
policy. The goal is not just have some archive of project
communication. I'm fully aware that the point is subtle and perhaps
I'm not doing a very good job of vocalizing this but the issue remains
that the important (at least to my understanding) of having a central
location for the project development is so that people know "where the
Discussion is happening". This is (admittedly subtle but) a very
important distinction between having a copy of a discussion sent to
the list and the discussion happening on the list.
The former leaves people not on GitHub raising their hand and no one
noticing until after the fact (if at all). Treating the dev@ list as
simply an archive of project communication means that fewer and fewer
people will be using it for the intended purpose of managing the
project. And this I think is the worst outcome of all. Its even worse
than just deciding to give anyone that can't or won't use GitHub the
finger because at least then we're being straight forward and honest.
The absolute worst is if people came to this list and were basically
hellbanned [1] from the project.
So that's the important point I'm trying to get across. People can
talk about CouchDB where ever and how ever they want. Whether over
beers or on PRs in forks on GitHub. But when that discussion comes
round to being part of the project and this community it comes to this
list. We can and should do our best to inform possible contributors as
well as make it as easy as possible to contribute to this discussion
forum as possible. Yes that includes writing tools to interact with
external forums where possible and it does include being accepting of
new tools and communities when possible. But we must be diligent to
make sure that this work doesn't change some of our core policies and
practices... like writing long screeds about mailing lists or
indentation or how much I hate merge commits.
[1] http://en.wikipedia.org/wiki/Hellbanning
On Fri, Mar 15, 2013 at 4:55 PM, Noah Slater <nslater@apache.org> wrote:
> I might also point out that he ML policy is not about ensuring that
> committers can do everything via the ML, or even about ensuring that
> committers can contribute to the project without ever having to use an
> external service. (Think about the fact that we're using Travis for CI,
> ReadTheDocs for documentation, and I do releases on AWS!)
>
> The ML policy is about making sure that a *copy* of all the important stuff
> happening is sent to a single place where committers are monitoring, so
> that we can operate via lazy consensus. (i.e. Speak up if you don't like
> what you're seeing.)
>
> If there's something happening on Github (again, TOTALLY outside our
> control — Githubbers gonna Github) and you want in on the conversation, I
> don't think it's unreasonable to think that you're gonna have to sign up
> for a Github account. (Same way if you want to play with Travis, you're
> gonna have to get a log in. Or if you wanna tweak our RTD setup.)
>
> This isn't about turning dev into some super awesome email-based command
> and control centre It's about making sure that important conversations are
> being widely read. That's it. And I think my proposal satisfies that. :)
>
>
>
> On 15 March 2013 21:44, Noah Slater <nslater@apache.org> wrote:
>
>> 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
>>
>
>
>
> --
> NS