couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: “Yes, and…”, not “But…” (Was: [PROPOSAL] Create mailing list)
Date Mon, 14 Sep 2015 10:52:46 GMT

> On 14 Sep 2015, at 12:08, Alexander Shorin <> wrote:
> Hi Jan
> On Mon, Sep 14, 2015 at 12:57 PM, Jan Lehnardt <> wrote:
>> We agreed on a “Yes and…”-style of feedback, and it looks like that we
>> are defaulting to a “But…”-style feedback.
> Could you explain what are "Yes and..." and "But..." feedback styles
> and how they are different?

Sure, I had hoped that just mentioning this recalls our previous discussions. Here’s an
example (sorry Michelle for picking on your example here, but it was freshest in my mind.
In general, I don’t mean to re-play this as it happened on dev@, and I don’t want to single
out anyone in particular, so I changed things a little):


“Hey, let’s create a design@ mailing list for designers.”

“That’s a bad idea, we already have www@ and nobody uses that.”


<after a few of these, the person with the original suggestion leaves the project>

“Yes, and…”-style:

“Hey, let’s create a design@ mailing list for designers.”

“That’s an interesting idea: safe spaces are important! We still have the somewhat dormant
(which is a different discussion) www@ mailing list for website stuff, have you considered
repurposing this?”

“Ah, good call, maybe that works, but I feel www@ isn’t as inviting a name as design@

“I can understand that. If we go down that path, what would be even more inviting than a
design@ mailing list? I can imagine that our mailing list system is not very approachable
for designers to begin with, maybe we should look at a Discourse instance or a Slack channel?“

<fruitful conversation continues>

* * *

If your read this and thing “golly, ‘But…’-style is a lot more efficient, we don’t
have a lot of people contributing in the first place, so cutting these discussions short is
brilliant”, just know that our #1 purpose as a project must be to attract more contributors.
Having more contributors is the #1 thing that makes sure CouchDB is a long-term success. It
makes sure that individuals don’t burn out, it helps with more diverse ideas making the
project better, it helps get us more stuff done overall. Long-term, it doesn’t matter if
2.0 is delayed by a couple of more weeks, but it does matter if the people who help shipping
2.0 leave the project right after, because it was such a burden to do that they lost interest
or simply burned out.

* * *


> --
> ,,,^..^,,,

Professional Support for Apache CouchDB:

View raw message