community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Louis Suárez-Potts <lui...@gmail.com>
Subject Re: slack
Date Mon, 10 Aug 2015 18:24:54 GMT
HI,

> On 10 Aug 15, at 14:10, Ajoy Bhatia <ajoy.bhatia@gmail.com> wrote:
> 
> Just wanted to make a comment on the mail from Louis Suárez-Potts <
> luispo@gmail.com>, in which he related his conversation with James H., a
> Slack engineer. Comments are inline below. Highlighting is mine:
> 
> So, I pinged the nice folks at Slack (and they really are nice!, or at
>> least the guy I communicated with), and asked them about:
>> 
>> * open source: No.
>> * the issue of uncaptured conversations, as Ted D. mentioned ("there is a
>> huge danger of *off-list discussions*…").
>> 
>> 
> Here, I interpret "off-list discussions" to mean: "discussions occurring on
> Slack that are not captured on the mailing list.
> 
> 
>> 
>> To the latter, which James H. of Slack recognised as important, he
>> suggested:
>> 
>> <quote>
>> 
>> ...our new-ish reactions feature:
>> http://slackhq.com/post/123561085920/reactions
>> One team I'm in has coopted a particular emoji to *flag conversations as
>> off-topic – a friendly but brief way to say "please take this elsewhere"*.
>> This probably wouldn't work for the social dynamics of every team, but it
>> does work in this particular case.
>> 
>> </quote>
>> 
>> 
> The Slack engineer (James H.) and Louis (see below) both seem to have
> misunderstood "off-list", and confused it with "off-topic". The two are not
> the same.
> 
> I further replied that in this case that the technical solution seemed
>> interesting but that *given the basic nature of the problem (it’s a human
>> thing), I’d guess that the solution will necessarily include discipline*.
>> Cutting off options is going to get increasingly hard and we (Apache) run
>> the risk of coming to seem fustian, stodgy, obsolete, old fashioned and
>> everything else. Perhaps—as with GitHub—discipline and then yet more
>> recognition of the importance of inclusive community, is the ticket.
> 
> 
> Thanks...
> - Ajoy

Hmm. I don’t think I misunderstood. Offlist means, I understand, what Benson, Bertrand,
et al. have underscored, conversations of consequence that take place off the designated Apache
list. The . It’s entirely possible that James H of Slack chose to interpret the conversation
as you suggest, but you err in thinking I did. That said I no doubt am absolutely guilty for
phrasing the plainest of language in ways that would make mazey doats of us all. (Clean narrative
is what I love, not what I have.)

I used to (and still do) urge the communities I work with to keep their conversations—all
of them—on the designated lists. I am not an advocate of roaming off list, however fun it
may be. I urge this discipline because stuff can happen, good or bad, and arise out of seemingly
inconsequential discussions. So, better to keep all on list. When I was doing OpenOffice.org,
I compromised with some communities venues (e.g., IRC channels) to a) agree that nothing happens
of consequence on IRC or anywhere; that only on-list discussions were of consequence; b) that
in some cases a copy-and-paste transcript (or archive URL) could work, but the it was not
desirable and in the cases of IRC archives of transcripts, better to arrange beforehand the
venue as a privileged one. The point then, as here, being that the aim of discussion was first,
community inclusion, and actually only second production; and that this was afforded because
it was understood—maybe—that more inclusion meant more production.

cheers,
Louis


> 
> 
>>>>> 
>>>>> 2015/8/11 上午1:35於 "Benson Margulies" <bimargulies@gmail.com>寫道:
>>>>>> 
>>>>>> I think it's important to recognize how the board and the
>> foundation
>>>>>> have handled this issue over time.
>>>>>> 
>>>>>> The absolute requirement is open decision-making. Avoiding
>> real-time
>>>>>> communications avoids many possible failures of open
>> decision-making.
>>>>>> (Not, of course, all.) After all, the simplest primrose path here
>> is
>>>>>> two people standing at the intersection of their cubicles. The
>> policy
>>>>>> has always been to sternly warn that the use of real time
>> mechanisms
>>>>>> involves risks of failure, and that failure involves risks of the
>>>>>> board's blunt instruments being deployed. Does all of this slow
>> down
>>>>>> some processes, and cause some people of limited patience /
>> boundless
>>>>>> energy to get frustrated? Yup, things have costs.
>>>>>> 
>>>>>> Just writing up the results on the mailing list isn't good enough
>> if
>>>>>> there is no real opportunity for people to question, deliberate,
>> and
>>>>>> change the course of action.
>>>>>> 
>>>>>> You want to have a bar camp, a con call, a slack discussion, a set
>> of
>>>>>> messages exchanged by carrier pigeon? Then it's up to you to make
>> sure
>>>>>> that you don't end up excluding people from the decision-making
>>>>>> process.
>> 


Mime
View raw message