Ajoy Bhatia <ajoy.bha...@gmail.com> 於 2015年8月11日週二 2:11 寫道：
> Just wanted to make a comment on the mail from Louis Suárez-Potts <
> lui...@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
>
>
> > > > >
> > > > > 2015/8/11 上午1:35於 "Benson Margulies" <bimargul...@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.
> >
>
