Slack Team

[notenociz]

A Slack team at something like dwyl.slack.com would be useful for the dwyl community:

• to gather
• to discuss
• to collaborate on projects and debates
• to organise/plan projects
• to keep track of the community
• to socialise
• to organise meet ups in
• to try cool tricks
• and more...

I suggest making one and adding it into the start here here for maximum impact. Also, don't most companies use Slack by now? If not, they should!

To save you time, get one for free here 😀

Let's do this!

[iteles]

@enociz Thank you for suggesting this and for all your initiative lately, so great! 👌
We totally agree that having a place where everyone can collaborate is essential (and I'm particularly enthusiastic about the fact that you're suggesting so many different ways!).

We actually already have a gitter channel for general dwyl chatl!
Gitter is by no means a perfect tool but most of the people we've spoken to in our community already use it as a daily tool and there's nothing worse than having to check multiple forms of communication to stay up to date - we felt that was quite a big barrier to contributions. They're also super supportive of open source initiatives like ours 👍

It might be that what we need to do is be more active with letting people know the gitter channel exists and to encourage more chat there!

[notenociz]

I don't like Gitter's experience but I'm fine with using it. I guess a Gitter badge should do well in letting us know.

[iteles]

I agree that the experience is certainly not perfect, but it's always improving and the guys at Gitter are so lovely! We should definitely take stock of the alternatives and evaluate them in the future for completion.

There should be a gitter badge visible when you open the start-here repo.

Do you see something different to the below?

[notenociz]

Nope,

Purrfect!

Wait, was that always there? If so, I should have gone to Specsavers (I'm probably blind).

[iteles]

Ha, yes, it's been there for a while now 😉

Thanks again for raising this!

[nelsonic]

Hi @enociz yeah, we prefer the UX of _Slack_, but we ❤️ the people @GitterHQ
@mydigitalself @suprememoocow ... so we will continue to promote & use their project.

We especially 😍 how https://github.com/gitterHQ #OpenSource most of their product code.
By contrast, https://github.com/slackhq only make the interfaces to their product open... the distinction is subtle but important...

If you have specific issues with the Gitter UI/UX I'm sure @trevorah will appreciate the feedback. 😉

[notenociz]

Love your appreciation of #OpenSource 😀 keep it up

[ghost]

@enociz (we think) #OpenSource is the #_Solution_ https://github.com/dwyl/intellectual-property 👍

[nelsonic]

@markwilliamfirth apparently, I don't have an account on slack for dwyl:

[newswim]

I'd love it if there were a DWYL slack channel, I tend to not use gitter for a few reasons (already having slack open, annoying notifications, somewhat awkward room system). +1 for slack!

[nelsonic]

@newswim while I like the UI/UX of slack,
I find that other people (who aren't getting work done)
use Slack to distract the those who are trying to get (focussed) work done... 😞

Read the comments on this: https://twitter.com/iamdevloper/status/857193510834982912

Slack is meant to boost people's "productivity"
but it ends up being a massive drain in practice.
This is well documented in several academic studies;
to get (valuable) work done we must focus,
IM obliterates any attempt at focus.

The argument proponents of IM use is
that they can contact their colleagues and get answers much faster.
(I totally get this!)
What most proponents of IM fail to acknowledge
is that instantly-contacting your co-worker/peer interrupts their flow.
And it might take them 25 mins to get back into their "flow".

Read:

• https://ux.useronboard.com/slack-i-m-breaking-up-with-you-54600ace03ea
• https://medium.com/planet-arkency/3-easy-tricks-to-be-less-distracted-when-using-slack-a22b7791b9a6
• https://www.groovehq.com/blog/stop-getting-distracted

Instead of thinking about how much work they could get done if they had no interruptions,
people concentrate on how "useful" IM was in an the handful of cases where it helped.

Instant messaging is great for "instant gratification"
but terrible for long-term success.
It's essential not to confuse "socialising" with peers via IM
with getting high value tasks done.
Most people don't make the distinction.

If you want to be highly productive, follow Cal Newport's advice and use instant messaging as little as possible:

https://youtu.be/zfoCyFvADtU

There is a better way, we are going to build it.
A way of getting answers to questions in a timely fashion,
where content is well organised, structured and searchable.
A tool that protects people's focus from interruption and
informs them of the highest priorities requiring their attention
when they do take a break from their highest value tasks.
❤️ ✅

[newswim]

I love this approach and the idea!

There is a really interesting project which tries to make daily/weekly meetings more organized, (https://github.com/ParabolInc/action)
They've picked a great stack, and have an equity-based system for encouraging OSS contribution.

I agree that there are huge flaws with chat and "chat for business" software, many of which were inherited from the earlier days, and few products have come along which address these.

To add to your last statement, I would really love to see:

• A single view with relevant information (who has tried contacting me, what is that priority?)
• Users should be able to send messages with a priority indicator, only truly important things should be the cause of broken focus. (Of course this requires an understanding of "truly important")
• Automatic responses to common questions

Basically something intelligent that values the time of people using it, and helps to maximize productivity along the way.

Sounds like a great project for DWYL!!! 😍

[nelsonic]

"Chat is great for occasional quick hashing things out, but when you leave it open all day in the corner of your screen, you're just asking for yourself not to be working. It's an all-day-meeting with random participants and no agenda". ~ Jason Fried https://youtu.be/ft-q9s2uxIQ?t=14m43s

[iteles]

⬆️ That is a amazing way of putting it!

[ghost]

@newswim there actually is a dwyl slack (http://dwylhq.slack.com/) it's just only used my myself and @iteles at the moment. We use it for rapid communication and when things aren't appropriate to share on GitHub. We have a number of private channels referring to different areas of the business that help organise and separate discussions. Each channel has a link to a google document related to the context of that channel. Personally I find the UX/UI of Slack much better than Gitter. It's certainly not perfect, but it's one of the better tools out there.

[iteles]

@newswim For reference @markwilliamfirth and I are using Slack as a trial and not using it for widespread dwyl communication - that is all done through gitter.

Personally, I intensely dislike using Slack and this dislike has only grown in the last 2 months of usage. My biggest issues with it are:

• No 'read' notification so you never get the peace of mind that someone has looked at what you have said unless they take the time out to actively acknowledge it, wasting their time (I never use it for urgent comms but for example, if I mention that I'm going to be working from a different location the next day, I would like to know people have seen that message without having to tap them on the virtual shoulder to double check)
• What feels like dozens of clicks to switch between orgs and conversations, particularly on the phone
• It CHEWS through battery on my phone, way more so than gitter
• The unread count on my phone often takes minutes to go away and is usually incorrect, wasting my time
• Does not load any content when the network is anything below perfect (i.e I can still interact on gitter - though slowly - when my network is poor, but Slack doesn't even load)
• Closed source

[ghost]

@iteles I get the impression from your comment above that you dislike the application and would like us to cease using it?

[newswim]

It's good to accumulate these levied issues, hopefully they roll into the product definitions for this shiny new BETTER thing 😉

I can echo the points @iteles makes, and think an OSS solution which addresses them would be a godsend. A productivity app that actually helps with productivity.

[iteles]

A note here also that I edited @markwilliamfirth's comment above to remove a reference to potential 'very long' timelines for the chat application - we haven't quite defined these yet and I didn't want us to be misleading, sorry @markwilliamfirth 😊

[nelsonic]

@newswim funny you should mention "product definitions" ... 😉
I was just in the process of writing up a "User Story"
for the one thing I miss from Slack when I'm using other chat apps ...
see: dwyl/chat#33

Slack has got several things "right", Stewart Butterfield and his team have built a really good product!
But they have also got several things horribly wrong and ...
"as a user" I am unable to make improvements to "closed source" products
even if I am technically competent and could easily add the feature
while following all the necessary coding standards/workflow etc.
i.e. Closed Source software is fundamentally flawed and we are going to make it obsolete.
(Yes, I know the irony of this statement considering the fact that the "core" of GitHub is very much Closed! But, I use GitHub to get my actual work done whereas "chat" is merely a distraction until I can sync it with my work and make people aware of the fact that I am in the middle of something difficult without having to manually update my "status" ... I/we can easily leave GitHub, but I don't think the alternative (GitLab/BitBucket/etc.) are "better", yet!
The reason I don't want to be "locked in" to a closed source chat app/system is that I would lose "control" of my workflow! if I start using Slack for work, people will start expecting me to be "always on/available" and , anyone who has read "Deep Work" knows this is a terrible idea...)

In my experience the people who really value their time
don't keep chat apps/windows open
because chat (notifications) destroy any attempt at concentration.
It's a widely known fact that "multi-tasking doesn't work".
Which means that people either keep a chat window open,
or they focus on their important tasks.

So we also need the ability to automatically disable all notifications for someone
when they are in "focussed mode". see: dwyl/chat#35
(i.e. when you are working on a task and should not be interrupted unless it's an emergency!)

[ghost]

@nelsonic not sure if you're aware of the do not disturb feature?

https://get.slack.help/hc/en-us/articles/214908388-Do-Not-Disturb-and-snooze-settings
https://get.slack.help/hc/en-us/articles/214888418-Set-default-Do-Not-Disturb-hours
https://api.slack.com/

[nelsonic]

@markwilliamfirth not sure if you read the issue I opened: dwyl/chat#35 (and linked to in my previous comment) ... Not only am I aware of the Slack API but I have built an integration using the API and seen it's limitations!!

Incomplete Feature

Yes, Slack allows users to set "Default Do Not Disturb Hours" which is good. (on the surface...)

Does it sound like a good thing that an "Admin" can "override team members' own custom settings"? Does that seem like a way to protect people's focus time or dictate when they must be available?

Miscommunication

Slack offering a crude way to set a "Do Not Disturb" is only partially addressing the problem.
And, as we all know, partially addressing does not solve the problem; it often makes it worse!
This leads to miscommunication with/from your colleagues:

• "But you didn't set your Do Not Disturb, so I didn't know you were busy"... or
• "Your Slack profile always says Do Not Distrub, are you avoiding teamwork?!"

When actually you have a deadline to deliver something important that requires your full attention.
People shouldn't have to manually set "Do Not Disturb" ... that's more work (for the user)!!

Clicks Cost Real Money!

Let's run some quick numbers for fun ... (and so we can close this issue!)

Slack's token implementation of the "Do Not Disturb" or "Snooze Notification" feature
doesn't allow you to be "flexible" without additional manual input/configuration.
While I would love to have a 100% Fixed Schedule that never deviates
we can all agree this is totally unrealistic in practice.

if it takes an average person 2 seconds to manually update
their "Snooze Schedule" 10 Times per day¹ a day, it's 20 seconds.
20 seconds per person per day, surely that's "not-a-big-deal" right...?
Yes, it sounds "insignificant", but ...

• Multiply: 2 seconds x a 1,000 people² (i.e. 20k sec or 5.5 hours per day)
• Multiply: 5.5 hours x $20/hour³ ($110/day)
• Multiply: $110/day x 260 working days in a year that's $28,600/year
  and suddenly this poorly-implemented feature is costing the company real money!
  does that still sound like a good use of time/money to you...?

This ONE Feature is Worth 1/3 Slack's ENTIRE Revenue for the Year!!!

Slack has 1.25 Million Paid Users and $100M/year in Revenue
Sticking with our previous reasonable assumption that it takes people 20 seconds per day to set their "Snooze Notification" or "Do Not Disturb" settings (trying to stay productive and avoid interruptions by communicating with their colleagues when they are/not available)
average people are paid $20/hour and 260 working days per year ...
this is 5,200 seconds / year or 87 minutes or 1.44 Hours.

• Multiply: 1.44 hours x $20/hour we get $28.88 per person per year
• Multiply: $28.88/person x 1.25M

Result: $36.1 Million / Year of wasted time on updating Snooze Settings.

Automatic & Effortless Saves People Time

What I am proposing is that we make the "Do Not Disturb" Automatic and Effortless based on the person's current/active Task/Timer so that the communication tool helps people communicate effectively. Not force them to perform more repetitive clicking.

Yes, We could use the Slack API to do this, however, as I pointed out in the issue I created yesterday (before your API comment), if our product was even modestly successful we would rapidly hit Slack "API Rate Limits" and then be beholden to a Company with an Opaque/Fickle decision making process to grant us more API Requests...!

Do You Want To Build Features for a Closed Platform...?

Also, if we build a feature for the Slack Platform using their API we are doing 3 things:

• Helping to perpetuate Slack's closed-source dominance
• Limiting our own creativity by the limits (both function and rate) of their API
• Giving them a ("killer") feature they can integrate into their core product and eliminate us.

Yes, We would "get access to their 1.25M customer base" as they point out in their API marketing... but those customers still belong to Slack, they are merely giving us "access" to the users, which they can easily revoke at any point and release the feature themselves.

Stop Following the Herd and make Something New / Better!

@dwyl's plan is not to follow the "herd".

Focusing on how good Slack is guarantees that we won't realise how much better it could be!
And even if we do spot how much better it could/should be, we are powerless to improve it because it's CLOSED.

I don't understand why we are still discussing this...
I thought we had made it clear.
We are not going to use Slack.
We are going to make "instant messaging" (interruption) Obsolete!
We cannot build the future if we are stuck using the tools from the past!

How many people at Apple use Nokia Phones?
How many people working at Amazon buy their books from Barnes and Noble?
How many people working for Nike are wearing Reebok trainers?

I don't know how else to communicate this...?
If I say: "We are building a 'COMPETITOR' to Slack"!
People will immediately proclaim that I'm "insane"!
Why would anyone want to "compete" with Slack?!?
Surely they have "solved" the problem of "Chat"...?!?!?!?! Right....?!?
NO! The issue is that Slack have focussed on the wrong problem!!
They should have solved the "Communication Problem" not the Instant Gratification One!
Communication is way more than just having an Instant Messaging Client with an API.
Chat is only one tiny part in Communication and it's the most disruptive/distracting part!

I agree that Gitter isn't great.
Yes, I don't like Gitter's notification system and "weird room" system.
I agree that we need a better way to communicate @dwyl!!
But what we have to agree on is that having multiple forms of communication is Chaos!
Email, Chat (Gitter), Google Docs, GitHub, Hangouts messages, SMS, WhatsApp, etc...
Too many channels is a recipe for miss-communication.
We aren't going to replace Gitter with Slack.
What we are going to do is build a simple Communication System
that protects the time of the Most Valuable People in the team from constant interruption.

Let's focus on building a great product not perpetuating someone else's business!

@markwilliamfirth please focus your energy on helping us to make our product: dwyl/chat#37
(or become a sales-person for someone else if you don't want to help make anything new...!)

[ghost]

@nelsonic the point is that before we're able to build the communication system we need an effective stopgap that we can use at dwyl.

The Slack do not disturb feature aligns with the premise of Deep Work and the Focus Hub offering - it allows for rhythmic periods of focus that are set and agreed with everyone. This means everyone knows when it is ok to talk and time to focus. The setting only needs to be set once from the admin console to be effective across the whole organisation.

Users dynamically altering the focus / communication state according to tasks is still quite a way off, whereas this is an effective stopgap that aligns with the deep work ethos, our offering and short-term vision for productivity.

[nelsonic]

@markwilliamfirth, you are forcing me to make a decision I don't want to make. 😞
And I'm NOT talking about Slack.

[nelsonic]

https://abe-winter.github.io/plea%27s/help/2018/02/11/slack.html

[newswim]

So true, even though I am basically forced to use Slack every day. The devil you know...

[nelsonic]

"Unslacking": https://beberlei.de/2018/10/28/unslacking_tideways_company.html
comments: https://news.ycombinator.com/item?id=18320968

[nelsonic]

[nelsonic]

Slack Is Not Where 'Deep Work' Happens: blog.nuclino.com/slack-is-not-where-deep-work-happens
Discussion thread: https://news.ycombinator.com/item?id=19643298

[nelsonic]

Read the top comment in this thread: https://news.ycombinator.com/item?id=23297113

"Slack has totally become a drag on productivity and a net negative. Channel and message overload is arguably not much better than the email system it is meant to replace."

"My prediction is that Slack will be replaced quite quickly by the first tool that really nails remote messaging and coordination. Slack is not it."

[nelsonic]

This is what's wrong with having multiple closed channels of communication: outmoded/discuss#643 (comment)
I'm trying to understand why I'm seeing an error in the shot library for dwyl/labels#92

How helpful is this response (and immediate closing) of the issue?

This issue was linked to from: outmoded/hapijs.com#571

This is super beginner-friendly. 🤦

"Outmoded" indeed. 👍