> On 14 Sep 2015, at 18:49, ermouth <[email protected]> wrote: > >> Have you ever played "Dungeons and Dragons"? > > Sorry, I played Civilization. What I learned was that saying ‘No’ at right > moment is much more important to have excellent score, then saying ‘Yes’ > each time ) > >> For example, in the oauth2 discussion > > As for oAuth, I think @CouchDB has a lot of readers, and asking them does > anyone use oauth, is more elegant way to decide should feature be dropped.
I already know the answer :) — Also, why didn’t you bring that up in that thread? Best Jan -- > > ermouth > > 2015-09-14 17:38 GMT+03:00 Jason Smith <[email protected]>: > >> Have you ever played "Dungeons and Dragons"? >> >> I think the "yes-and" style is more about continuing the momentum of the >> conversation, and also having fun! >> >> The "yes-and" style is independent of your opinion about the matter, or the >> facts of its consequences. To me, it is about being Socratic: say "Sure!" >> and then ask what the next steps are, or what the expected consequences >> will be. >> >> For example, in the oauth2 discussion, I think Jan used a bit of "yes-and" >> style, when he said "Yes, let's keep oauth2, provided a developer fixes its >> bugs; otherwise not." And I think the community collectively answered: >> "Yes, let's throw it out." >> >> On Mon, Sep 14, 2015 at 8:22 PM, ermouth <[email protected]> wrote: >> >>>> I think it comes back to trust, if we all trust each other >>>> that we have the best of the project in mind >>> >>> If @kxepal says there is no activity in www@ – he is right. Facts are >>> stubborn things. If he predicts there will be no users in design@ with >>> current approach – he is right. >>> >>> I can‘t imagine @kxepal don‘t trust you, or Robert, or Michelle. Surely, >> he >>> trust. He just pointing out real problems, and this is absolutely >> ortogonal >>> to trust. >>> >>> Not everyone pointing out a problem can immidiately propose a solution. >>> Issue fixing starts from bug itself, not from patch. And I can‘t imagine, >>> how you can start bug report with ‘Yes, and...’. There is nothing >> barbarian >>> in ‘It won‘t work in this way’ or ‘But how about this?’. >>> >>>> That’s the kind of stuff that makes we very very tired participating >> here >>> >>> Sorry, but just repeating your own words: ‘If that makes you want to >>> unsubscribe, farewell’. Writing it not to prick you, but to point out, >> that >>> if you issue rules about friendliness, you better obey them by yourself >>> first. >>> >>>> [Alexnder Shorin] What really hurts conversations is false-positive >>> feedback, when you >>>> have to lie people and lie to yourself about foreign ideas. >>> >>> Absolutely. +1000. >>> >>> ermouth >>> >>> 2015-09-14 15:49 GMT+03:00 Jan Lehnardt <[email protected]>: >>> >>>> >>>>> On 14 Sep 2015, at 14:42, ermouth <[email protected]> wrote: >>>>> >>>>>> I’m suggesting a way how we can adopt a proven way >>>>>> If that makes you want to unsubscribe, farewell. >>>>> >>>>> That is exactly what I called iron ordnung. Extreme unfriendliness is >>>> only >>>>> allowed for your here, Jan. The one thing I fear now is that people >> are >>>>> afraid to say ‘but’, or take a contrarian position in general. How >> can >>> we >>>>> avoid that? >>>> >>>> I think it comes back to trust, if we all trust each other, that we >> have >>>> the best of the project in mind, we shouldn’t have a problem >> disagreeing >>>> with each other. >>>> >>>> If you come at this is discussion from “if this happens, I’ll leave the >>>> project”, then you probably don’t trust me to make good suggestions >> about >>>> our culture. How can I improve that? >>>> >>>> >>>>> Without phrases ‘You don‘t like it? Farewell’, surely. >>>> >>>> I’m sorry for the harsh tone, but I’m also really fed up with lazy >>> excuses >>>> of why we shouldn’t be a better community, and I especially called this >>> out >>>> in my original message, and now we already have a number of messages on >>>> this thread that have nothing to do with the actual issue. That’s the >>> kind >>>> of stuff that makes we very very tired participating here. >>>> >>>> Best >>>> Jan >>>> -- >>>> >>>> >>>> >>>> >>>>> >>>>> ermouth >>>>> >>>>> 2015-09-14 15:26 GMT+03:00 Jan Lehnardt <[email protected]>: >>>>> >>>>>> Of course, this could have gone this way: >>>>>> >>>>>> “That’s an interesting approach, is there more literature on how and >>> why >>>>>> this is supposed to work?” >>>>>> “Here’s a bunch of links: …” >>>>>> “Gotcha, the one thing I fear now is that people are afraid to say >>>> ‘but’, >>>>>> or take a contrarian position in general. How can we avoid that?” >>>>>> “I think it comes back to trust, if we all trust each other, that we >>>> have >>>>>> the best of the project in mind, we shouldn’t have a problem >>> disagreeing >>>>>> with each other.” >>>>>> >>>>>> But then again, that would be a sign of the method working… >>>>>> >>>>>> Best >>>>>> Jan >>>>>> -- >>>>>> >>>>>> >>>>>>> On 14 Sep 2015, at 14:15, ermouth <[email protected]> wrote: >>>>>>> >>>>>>> Well, next good step is to write it in CoC. Something like >> “Starting >>>> post >>>>>>> with ‘But’ is unwelcomed here’. You surely attract tons of >>> contributors >>>>>>> with this. >>>>>>> >>>>>>> As for me the only desire after reading this is not to subscribe, >> but >>>> to >>>>>>> unsubscribe. Imposed iron ordnung is surely far more uncomfortable, >>>> then >>>>>>> posts, starting with ‘but‘. >>>>>>> >>>>>>> Also I see this policy just leave important questions undiscussed – >>>>>> nobody >>>>>>> dare to say ‘but’. >>>>>>> >>>>>>> >>>>>>> ermouth >>>>>>> >>>>>>> 2015-09-14 13:52 GMT+03:00 Jan Lehnardt <[email protected]>: >>>>>>> >>>>>>>> >>>>>>>>> On 14 Sep 2015, at 12:08, Alexander Shorin <[email protected]> >>> wrote: >>>>>>>>> >>>>>>>>> Hi Jan >>>>>>>>> >>>>>>>>> On Mon, Sep 14, 2015 at 12:57 PM, Jan Lehnardt <[email protected]> >>>> 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): >>>>>>>> >>>>>>>> >>>>>>>> “But…”-style: >>>>>>>> >>>>>>>> “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@ is.” >>>>>>>> >>>>>>>> “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. >>>>>>>> >>>>>>>> * * * >>>>>>>> >>>>>>>> Best >>>>>>>> Jan >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ,,,^..^,,, >>>>>>>> >>>>>>>> -- >>>>>>>> Professional Support for Apache CouchDB: >>>>>>>> http://www.neighbourhood.ie/couchdb-support/ >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> Professional Support for Apache CouchDB: >>>>>> http://www.neighbourhood.ie/couchdb-support/ >>>>>> >>>>>> >>>> >>>> -- >>>> Professional Support for Apache CouchDB: >>>> http://www.neighbourhood.ie/couchdb-support/ >>>> >>>> >>> >> -- Professional Support for Apache CouchDB: http://www.neighbourhood.ie/couchdb-support/
