The best approach I've come to over the years is "don't make people think" - so, if you have the time - make something almost zero effort to see that it works and zero effort to apply.
This could mean screenshots - or sometimes something like a youtube video, or just logs of before and after.
Show visually the before and after, and try and write descriptive titles etc.
If it's github, then a PR (instead of just an issue).
Having said that, I don't always have the time.
There are also slightly more dark patterns, like if you are fixing something including "broken" in the description of the bug will grab more attention.
[EDIT]
As an example on this PR:
I would have written a title like:
"Don't fail on filenames over max length on Windows and Linux"
In the description, try and write the thing that is fixed first (you dive into the implementation) so that if someone only reads the first few lines they still know what's up.
Then dive into the implementation.
Imagine the person has very little attention span - maybe they are scanning the bugs while their small child is bugging them, you need the important info first, and you need to grab them (but don't go as far as click bait).
On a similar thing, use hyperlinks when you mention other bugs (e.g. you mention) #15024 - just make everything as little effort for them as possible.
This could mean screenshots - or sometimes something like a youtube video, or just logs of before and after.
Show visually the before and after, and try and write descriptive titles etc.
If it's github, then a PR (instead of just an issue).
Having said that, I don't always have the time.
There are also slightly more dark patterns, like if you are fixing something including "broken" in the description of the bug will grab more attention.
[EDIT]
As an example on this PR:
I would have written a title like:
"Don't fail on filenames over max length on Windows and Linux"
In the description, try and write the thing that is fixed first (you dive into the implementation) so that if someone only reads the first few lines they still know what's up.
Then dive into the implementation.
Imagine the person has very little attention span - maybe they are scanning the bugs while their small child is bugging them, you need the important info first, and you need to grab them (but don't go as far as click bait).
On a similar thing, use hyperlinks when you mention other bugs (e.g. you mention) #15024 - just make everything as little effort for them as possible.