Question: I sometimes come across bugs that do not have enough information to reproduce the bug, or worse, understand what the issue is in the first place. Usually, business analysts, rookie QAs & sometimes developers write nonsensical bugs like this. **Contrived** (for simplicity) examples - 

**Ex.1** I see a server error when I open this webpage, for this user. The username and password is xyz.

**Me:** Does the page give more info about the server error ? Did you check the network inspector of your browser ?

**Ex.2** I open the ecommerce webpage & add items item1 & item2 to shopping cart. Then, I see that the underlying CartService's api call getCartTotal response has Item 1 discount=0%. This is wrong. In ItemPriceService call getItemPrice(theItem) we have Item 1 = {$50, discount 10%} & Item 2 = {$100, discount = 0%}.

**Me :** So, you meant to say that in the shopping cart, any discounted item is priced at its regular full price. (...and the rest of the info in your bug report is the underlying details of the bug)

Due to such bugs, I often have to waste time in chatting with the bug reporters to understand & reproduce such bugs. How do I deal with such poorly documented bugs ?

**Some solutions I think might help.** Do you see any issues in these 
solutions ?

* Save 2-3 poorly documented bugs somewhere & make current employees & new candidates try to figure out what the basic issue is & how to reproduce it. Then, show them the well documented version of the bugs to understand how much pain others go through in understanding the bugs. I will have to ask management to do implement this solution.
* Create general guidelines for bug reporting, perhaps even specific guidelines for api testing, UI, database etc.
* Reject the bug saying that its not clear what the issue is.

Answer: 
If you are finding bug reports from QA engineers to be lacking enough clarity to reproduce and fix, this seems like an issue to bring up to the QA Manager. Are new QA engineers not being properly trained? Are more senior QA engineers not properly overseeing the work of newer engineers long enough?

Your first two bullet points seem like good ideas, but I'd avoid going directly from QA engineer to QA engineer. It should be a team effort between the Dev and QA management teams.

If you truly can't understand a bug report, rejecting (or if your system allows it to be put in a feedback state that throws it back to QA for review without actually rejecting it) it is fine. But doing this is unlikely to actually address the larger issue and make cause unnecessary friction between teams.
I like your solution to show and *discuss* the best. Let people experience what you experience. And *ask* them to help you so you all can do a better job. Be aware of the fact that not everybody understands your problem as it might seem 'logical' what is wrong.
The best way to illustrate that, I think, would be to show a vague/ambigious report and ask people to describe, for themselves, what they think is wrong.
Then let people share their ideas. The more they differ, the stronger your example and case might be. Use that as well for creating your 'teaching material'. 

Guidelines might help if they support the thinking about what and ho to report. If people use them as checklist it will become totally useless. 

And rejecting is always an option. Try to be provide information that let people help to understand why it is unclear. Otherwise you will become the guy that is always 'negative'.

As a side note: I think chatting with the bug reporters is part of the job. Having close communication is a great way of getting more & better information.