couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: Comments threads on Github
Date Fri, 15 Mar 2013 23:46:48 GMT
On 15 March 2013 23:20, Paul Davis <> wrote:

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

This is obviously nonsense. Discussion happens on IRC. Discussion happens
no JIRA, in the comments. The important thing is that *decisions* are taken
on the mailing list.

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

This argument is based on a flawed premise. There is no policy that all
discussion has to happen on the lists. Otherwise JIRA could not exist. Nor
would be allowed to use IRC. You say so yourself in the previous paragraph.

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

Why? You have provided no justification.

> While its easy to just say "because that's the way it is at Apache"

As I have already pointed out, this is false. This is not "the way" at

> the reason is that there are
> real people in this world that don't necessarily have the ability or
> the desire to use GitHub.

Without the "ability" to use a free, hosted web app? Who are these people?
Can you provide concrete examples?

And should a proposal be blocked because there is one or more people who:

a) want to contribute to CouchDB,
b) want to be involved in a discussion happening on Github,
c) but have "no desire" to use Github

Who are these people? And why should I care about the fact they have no
desire to use Github? The example doesn't even make sense. If someone had
no desire to use Github, why do they care about commenting on some activity
happening there?

And what about people who simply don't "desire" to use MoinMoin, or JIRA?

> Email is a much more basic tool with a much
> lower barrier to entry.

So use email, and ignore the PRs. Nobody is telling you you have to look at
them. (Though, by your own admission, you've been purposefully avoiding

I don't understand what you're suggesting though. Because YOU don't want to
use Github, or because YOU don't want to comment on PRs on Github, are
you... Expecting the PRs to vanish?

There is activity happening on Github. And we can either embrace that, or
we can stick our fingers in our ears and pretend it doesn't exist, and cite
phoney policy to justify a lack of desire to engage with those people.

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

You seemed to be suggesting that it was outlandish to expect that a
committer used some non-ASF provided service. That's the position I though
you were making. So I was pointing out that actually, as it stands,
committers on this project could, at various points, be expected to have
logins for a number of different 3rd party tools and apps.

It seems you're fine with this though, given your comment. Which is handy,
because the rest of your argument is invalid. ;)

The rest of your argument seems to be:

 * All discussion relating to the project MUST happen on the lists

This is false. I don't know where you got this impression. This is why we
can have IRC meetings. In fact, it was in recent months that I was having a
discussion in the Incubator with *board members* who were re-affirming for
me and the podling I am mentoring that discussion is okay to happen
*anywhere* as long as *decision making* is happening on the lists.

JIRA is a great example of this. Because you have tickets. And then you
have loads of comments on the tickets. And all that activity is happening
away from the lists. And you have to have a JIRA account to sign in.

But there's an even better example of precident here.

This is, basically, an ASF hosted pull request tool. That's basically what
it does. That's what you're seeing. A bit long list of pull requests. With
loads and loads of line by line commenting. And it's all happening away
from the lists.

Because this is totally fine. :)

> The goal is not just have some archive of project
> communication.

No. The goal is to enable decision making through lazy consensus. We do
that by posting changes and discussion to the list, and then people are
given the opportunity to speak up if they disagree with it.

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

Your understanding is wrong. IRC, JIRA, BugZilla, Review Board.

The former leaves people not on GitHub raising their hand and no one
> noticing until after the fact (if at all).

Nobody noticing? Eh? An email to the dev list with an objection is likely
to be noticed by quite a lot of people.

And again, because we have precedent here, your concern does not just apply
to Github. It applies to every single one of the other communication
channels we use.

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

Demonstrably false. JIRA, BugZilla, Review Board.

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

I have no idea what this section of your email was about.

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

False. When it comes to making a decision, it comes to the list.

And remember that at Apache, a decision can be as simple as stating your
intention. And that can be through a Git commit, a wiki diff, a JIRA
comment, a Review Board "ship it!" action, or.... A Github comment.

I really, really don't see why Github is *any* different from any of these
things. Least of which is our ASF hosted
I-Can't-Believe-It's-Not-A-Github-Pull-Request Board.

> But we must be diligent to
> make sure that this work doesn't change some of our core policies and
> practices...

I believe your understanding of our core policies are wrong, in this
instance. :

On 15 March 2013 23:36, Paul Davis <> wrote:

I'd just like to point out that no one has suggested anything anywhere
> close to this.

Read Benoit's email again. He essentially suggested shutting down the
mirror. :(

The fact of the matter is Paul, we have Github. It's a part of our lives.
Some people like it more than others. Boo hoo, in both directions. All I'm
trying to do is get a green light for us to move forward and make a slight
tweak to our integration.

If someone blocks this they will be leaving us in the current situation of
having PRs, and having a whole bunch of comments on them that nobody is
seeing and nobody cares about. Which make me very sad indeed.

Thanks for listening.


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