I have written a draft for the Reporting Bugs guide

[Leo Arias]

On Tue, May 9, 2017 at 10:06 AM, Alberto Salvia Novella
<es20490446e at gmail.com> wrote:
> Also understand that 95% contributors won't have the degree of persistence I
> have on dealing with conflict.

Also note that 95% of contributors won't cause as much conflict as you cause.

Which is not necessary a bad thing, when people take the time to reply
to you in some cases it means that they care.

If I may suggest something, do some real world experiments. This
changes are your idea of a better approach, it would be good to put
them to test with real new bug reporters. Organize a bug reporting
day, present people with the old and new formats, and gather feedback
and stats. Maybe some people will disagree with this approach too, but
you don't have to ask for permission to do this. The people who like
the idea will join, and those who don't will go on with their lives.
And my hope is that some of us on this mailing list will care enough
to join you and help new reporters. At the end you will have info to
adjust your proposal, and to support it while discussing.

There are all kinds of newcomers. So there is no single right way to
solve this problem. Take a look at the wild variety of README.md,
HACKING.md, CONTRIBUTING.md that are out there in github. I like the
idea of starting with a smaller page, because it would be like fresh
start, and we can add things slowly after checking what worked and
what didn't work. But I have no way of knowing if this is the best
possible option.

The best way I've found so far to help people getting started is
through mentorship. Which has the added benefit of giving lots of
feedback to the mentors that can then be turned into many different
FAQs and guides.

pura vida.
-- 
¡paz y baile!
http://www.ubuntu.com