Right now I'm in a situation working for a startup that posts a video of a bug with little to no detail at all and sends it off to dev to be fixed. If there is information included, there is no standardization so it can be frustrating having to hunt this information down. I understand in startups I will have to learn to operate in a realm of ambiguity; however, the team is so small that I could potentially fix this with a little buy in.
Somethings that I've seen work in my previous job were having:
-screen shots of current state and future state
-video of current issue
-steps on how to reproduce
Im new to the team and don't want to be "that" guy trying to change everything, so I don't want to come to them with any half baked ideas. Do you have an example of a strong story that I could use as a template for our tickets?
Improving the bug triaging process is something I'm very familiar with (I spent a lot of my career working closely with QA), so I have a lot of thoughts here. Before I go through anything though, I want to be clear that you should set your expectations realistically as you're working at a startup. A startup is going to value velocity above all else, and even if everyone wanted to refine a system, startups often don't have the infrastructure to do so. Adding process is often the enemy of speed as well - There's a good chance you won't get everything you want in this interaction.
That being said, I imagine the process should be something like this:
Ultimately, this entire situation is a big exercise in communication, so I highly recommend going through my Effective Communication Series if you haven't already.
In terms of what a good bug report/task would have, I largely agree with what you put down but have some additional thoughts:
Something that's missing from your list is some way to identify the user who filed the issue. This will be their user ID, email, or name in your product (you will almost certainly have the first 2 at least).
In general, as the software engineer, you should be empowered to automate this as much as possible. Let's say a user hits some bug using your app/website and emails your company's support team letting them know. It would be annoying to ask that user for further information like what browser/phone they were using and what version of the app they were on. This is information you have access to within your product code - You just need to log it.