It's no substitute for proper documentation, but it is very useful to be able to find and link to the conversation that led to creating a ticket, considering how often a critical detail gets left out of a ticket description.
What I wish Slack offered is the ability to move existing messages into threads, close those threads, and give them an explicit conclusion. Webforums gave their moderators the power to do that; I think any participant in a Slack channel should be able to at least propose doing that, but alas Slack doesn't give that power to anyone!
> It's no substitute for proper documentation, but it is very useful to be able to find and link to the conversation that led to creating a ticket, considering how often a critical detail gets left out of a ticket description.
It's worse than email, because emails at least almost always have subjects and the latest one usually contains most (if not all) of the thread. Email clients usually have a feature to save a message to some kind of file, and I usually attach that when creating a ticket (or working with one I didn't create).
My experience with Slack/Teams is like team using one email thread with the subject "team stuff" that they constantly reply to with fragmentary messages that are very difficult to decipher without full understanding of the context at that moment. Everything's jumbled together and impossible to piece together later.
IMHO, chat is only for things that are 100% ephemeral, and if there's any chance you will need the information later, you better immediately switch to email and summarize the previous conversation in complete sentences.
I agree that it's worse than email but for different reasons. I've found that when writing an email, people will put more time and effort into giving a complete picture in the initial email. In Slack/Teams, people give very brief descriptions that you have to ask half a dozen questions in chat or call them to figure out what they actually mean.
> I agree that it's worse than email but for different reasons. I've found that when writing an email, people will put more time and effort into giving a complete picture in the initial email. In Slack/Teams, people give very brief descriptions that you have to ask half a dozen questions in chat or call them to figure out what they actually mean.
Yeah, that's a major component of what I was talking about, which you called out more clearly than I did. With email, people tend to compose standalone artifacts that convey a more complete idea, but chat messages are just fragments. Maybe if they were properly organized you understand the conversation later, but the fragments are interrupted by other stuff so it's too hard to even piece together the whole conversation without missing something important.
I find things with search in slack every single work day, and find it exactly as difficult/easy as searching my email, and vastly less painful to organize.
> It's no substitute for proper documentation, but it is very useful to be able to find and link to the conversation that led to creating a ticket
It is? Whenever I click on a Slack link, it opens my browser and takes me to the Slack SSO for my company. I click the "Login" button and it takes me to my list of "Workspaces" (of which I only ever click on one). I then click on the one workspace I use, and nothing. It's just like I logged in from scratch. The link is totally gone now. I can now manually paste it into the address bar again and there's a 50% chance it will take me to the conversation I wanted, but maybe not because Slack.
Maybe your browser has strange cookie settings? It's just two clicks for me: I click the link, then I click “open in browser” (if I remember right) and it jumps to the message.
It drives me up the wall when we open a ticket, it remains without updates, but communications end up spread between email, Slack, some meeting we had six months ago and a letter sent by messenger pigeon to a coworker three provinces over.
Put it in the ticket. That’s why we have the ticket.
Yeah but then the person opening the ticket would have to go to _effort_ to actually usefully describe the issue, document the decisions etc and we couldn’t have that.
Much better to write a ticket with a vague headings only, assign it to someone and ablate responsibility for everything else to some other person. /s
Generally, if it's not an issue, we wouldn't be talking about it.
If they're asking a question, it becomes pretty obvious within the first few statements if it's an issue or not, even if it's one about missing documentation.
Ideally yes, but in reality it’s hard to keep synchronous conversation via a tracker which is usually not a real time chat. Usually it’s important to clarify reported issues vs whether it was correctly understood right away.
> which is usually not a real time chat. Usually it’s important to clarify reported issues vs whether it was correctly understood right away.
The summary/title of issues can be edited, as needed, and clarifying summary comments can be made.
But you're right, it's not exactly the same. People with language barriers sometimes struggle with "not real time" conversations. Others feel if they're writing something in an issue tracker, it's somehow special, so they have to be incredibly formal, and are afraid to be wrong, ask questions, etc. Some people who are great at speaking are terrible at "slower" forms of communication. I think this does limit those types of people, if you completely close off chat.
if really enforce this then I'm curious how you maintain high quality of discussion in there. Slack for me is like an explicit outlet for all the low-quality peripheral discussion that causes problems or confusion if it ends up in the ticket itself. There's definitely a question of discipline in ensuring that info ends up back in the ticket, but it usually just comes down to finishing up the slack conversation with "Can you update the ticket with this?" and they copy the useful parts, put a link to the discussion thread if it's useful and we're done.
Why is this a requirement? You have low quality discussion, in the ether, or you have somewhat constrained discussion, in the issue tracker. You can always "to summarize the above", but if you forget, it still exists where you can find it. At least it's somewhere topically relevant.
Our issue tracker lets us edit other peoples comments. This is nice for linking statements/questions to other issues.
Before 'Slack' I trained people out of asking me email questions by putting the answers in the wiki. At first I had to create the wiki pages to explain what would have been in the email, but over time people became self service. There are some negatives to this approach but mostly reducing certain classes of interruption are a good thing.
Wikis are precursors for dead tree documentation. It's both a place to store highly volatile pieces of information, and a place where you can start documentation, copy-edit it for months or years until it's just right, and then move the contents into 'real' documentation.
In the Slack age, we need a pipeline that starts in chat, moves to the wiki, and ends in capital D documentation. It wouldn't even have to be that hard. You could simply vomit out the contents, or you could try to be a little more sophisticated where you treat one participant as the author of the sections of the document and the other authors providing the copy for those sections. The goal is to rescue the contents before they disappear, either for real or just due to SNR.
Post-back of jira ticket mentions (or $tracker of choice) are highly useful. Making a channel with issue name is another (crappy) way to do it.
I would love unification in the tracker to every mention of a ticket, from Slack comment to Branch/commit/github mention, and every build system as well.
Jira with DVCS gets pretty close, and is much more useful after using a bot which can do a post back to a reference in the slack message.
We actually have that functionality for teams/private communities. I'm working on a tool called Linen.dev and we can move messages and have an open close state with threads.
> find and link to the conversation that led to creating a ticket, considering how often a critical detail gets left out of a ticket description
I worked with a Slack bot that would create a ticket and include link to the Slack thread and copy of the entire thread right in the ticket description. Very useful.
I work as non software type of engineer my work started using Microsoft Teams when the pandemic kicked in (from what I understand Teams and Slack are roughly equivalent to each other).
I find the organization and layout of Teams quite useful. I'm normally working on multiple projects at a given time so having a different "group" in teams for each of the projects makes a lot of sense for me. Previously I made heavy use of folders in outlook I'd make a new folder in my inbox for each project I was working on. I have email folders (and before folders existed PST files) going back 15 years now.
In order for this to work I'd have to curate my inbox by manually filing each email into the appropriate folder as it arrived, Teams kind of does the equivalent of this by default.
Managing and sharing files between people involved in projects has greatly simplified things previous depending on project we'd use a combination of email (has file size limits for attachments, no built in versioning when people are emailing around multiple revisions of the same powerpoint pres for example), Sharepoint document libraries (really hard to add people to sharepoint groups (maybe it was just way my work was setup but sharepoint security was really draconian, access control basically needed a full time admin to make it workable) and Network shared folders (needs VPN, active directory permissions etc). The way it works now (at least with how my work has it set up) once you are added to a group all the files that have been shared are accessible - having to file tickets to get access to shared folders or get added to groups in sharepoint is a thing of the past.
For long term management of documentation my workplace used to have a physical library with dedicated librarians(I think this dated back to 1960's and 70's). Keep in mind for a lot of technical engineering work etc there are legal requirements to keep information archived (for 50+ years sometimes).
The physical library disappeared in the early 1990's I think (long before my time) all of the physical docs were scanned and digitized we had some ancient MS Dos era software (looked like old early 90's software with a text user interface) I think it was called Q and A or something like that. It functioned as digital index for our at one point physical library. We used this for many years basically everything was archived as a PDF and the index in this DOS software was kept up to date. At some point someone used OCR on all the ancient pdfs which kind of worked and greatly improved searchability of our library.
When I first started we were in process of using some java based web interface to replace this ancient MS Dos software, I can't remember what it was called but I think it was mostly used by Lawyers and people in legal profession, kind of worked for storing technical engineering reports and technical drawings but wasn't really built for that purpose. It's still around people really hate using it. I believe there is a desktop client which might be ok to use but I've only ever accessed it through the web interface which is horrible.
In more recent time we trialed using some software called Confluence but it kind of fizzled out and there has been limited use of Open Source Media Wiki software.
What I wish Slack offered is the ability to move existing messages into threads, close those threads, and give them an explicit conclusion. Webforums gave their moderators the power to do that; I think any participant in a Slack channel should be able to at least propose doing that, but alas Slack doesn't give that power to anyone!