Comment 7 for bug 1774404

> We do already have this page, on the website, about writing bug reports

That's the one I linked an as you noted, too, it certainly could use some improvements. I'm afraid it does not serve its purpose particularly well right now (it's too long and not structured enough with the important information being too well "hidden" like I think is unfortunately the case for a lot of content on the website).

I think this page could/should serve as a first point of contact for all channels of communication (after an overhaul) and could also be linked from the bug tracker then.

> flowchart type of document

This is the first I hear of it and I have no idea what this is about (probably not the scope of this bug though either...). I'm not sure if such a format could work - if it's very well done maybe, but if it's only pretty but does not convey content we're where we started.

What I imagine could work for that page:
- a short and concise introduction (e.g. bulleted list) what information
  needs to be in each bug report
- a slightly longer explanation (not more than a paragraph) how that
  information is used by triagers and developers (i.e. why important?)
- link to launchpad
- new chapter on the lifecycle of a bug that explains the stages each bug
  goes through, what triagers / developers do and how the reporter can
  (and should!) help with the process.
  This can use some of the existing content, some from the essay I linked
  and maybe some newly created content.
- At one stage debugging/gdb will come up. I'd not include this on the
  page but link to [1] instead (which needs some updates, too, but
  that's even farther off the topic).

Either way none of this will actually help with the actual issue this bug is about: The content we enter into the description field on Launchpad.
We need to make sure people read it (we can be creative! I tried...) otherwise all the content we can come up is in vain.

I'm sure once we move to GitLab we'll have better options, until then we need something functional (instead of big plans for the future), so I invite you to say something new about "the 15 lines worth of warning symbols and explanation points" after all ;-)

Improving this short term seems more important then to get it absolutely right sometime in the future, and many lines of warning symbols might seem intrusive but at least achieved their goal...

[1] https://inkscape.org/develop/debugging/