This is a good writeup. My company uses Slack for communication, and we love it since it's browser-based and therefore platform-agnostic. We also had a group write a custom integration that assists people in carpooling to lunch.
I do have some conversational criticisms:
Comments in source code doesn't work as well as one might hope; nobody wants to try to keep comments up-to-date after the fact. I believe code should be self-documenting: do a solid job of naming classes, methods, and variables, and you'll be better off.
I also have to disagree with, "put low-level requirements in ticketing systems." In my experience, adding extra unnecessary steps to software development will only bog teams down (and they probably won't follow through with it consistently, anyway). My teams deal with product managers which write the tickets/cards/stories for us (they give us work to do, and we do it) and so it wouldn't make any sense for them to write anything more detailed than the high-level requirements.
Thanks for reading and for leaving a comment!
To a degree, I agree with you. However, I still find usefulness in sparse comments that explain why something unintuitive was done the way it was, often linking to external resources like relevant bugs in third-party libraries or services, the language itself, etc.
Again, in general, I agree. However, it depends on the nature of the work being done and who's writing the requirements. As an example, my workplace recent began a large-scale effort to cull some of our technical debt. The developers are the better people to write requirements in that instance because they're familiar with the nature of the debt and the best way to go about resolving it. I suspect this also varies on a more general basis from company to company; some may put high-level requirements in requirements documents and lower-level requirements in ticketing systems.