@bagong wrote via Gist:

Would it be easy to distinguish feature requests/suggestions from bug reports? I feel this template lacks some clearness because it tries to accommodate both purposes.

Unfortunately we don't have a way to swap out templates. I think the template is (rightly) more oriented toward bug reports. luckily, there are .md comments, so nobody will see the messy "if this do that" stuff. i am open to ideas to improving it, but i think any template will be much better than none.

i'm hoping that these formats will serve as a good intro-by-doing to new contributors, and a convenient reminder for experiences ones (i often forget what info i should include in my issue reports)

I would recommend making it a bit more minimal. I have been known to just give up filing a bug when I'm being asked 5 questions.

Usually most of the questions are irrelevant after you've stated what the basic problem is.

eg.

1
--
## Context
  |   |   | +<!--- How has this issue affected you? What are you trying to accomplish? -->
  |   |   | +<!--- Providing context helps us come up with a solution that is most useful in the real world -->

As an already frustrated user this question seems silly to me. It makes me (the average user) want to type things like "how about the thing doesn't fuck up all the time, amirite ?"

Steps to reproduce, code fragment and error stack are essential. Those are great.

I would recommend making it a bit more minimal.

Any particular section(s) you would like to remove? They are all helpful IMO. Would you be open to changing the wording to make it clear that some sections are optional?

I have been known to just give up filing a bug when I'm being asked 5 questions.

We would be fine with fewer bug reports IMO. I want fewer, higher-quality submissions rather than "these 10 things don't work the way i want, can you spend 20 minutes playing with each of them or explaining why i'm mistaken?"

these templates are making it clear that we expect "the community" to do its part in the development cycle. We are not just a dustbin for half-baked ideas and "my code isn't working". sorry-not-sorry if this sounds hostile. i really avoid sifting through open issues here because to know how to fix most of them, i have to do a ridiculous amount of research that could have been recorded by the OP while the iron was hot. i disagree that this is our responsibility; judging from the current pace, virtually nothing gets done that way. and besides, i'm sure (from seeing what happens to repos with similar templates) people who want to ignore them, will. it's a template, not a police officer.

on a more practical note, if we remove the section about "what os are you using" we lose out on reminding people to add that information when it's relevant. if we remove "what is the motivation" we likely miss out on cases where that would be important. etc. etc.

Usually most of the questions are irrelevant after you've stated what the basic problem is.

How many of the first page of issues are clear enough that you definitively know what the problem is and how to solve it after reading the title? For me, it's around 6 or 7 out of 25 (20?). Maybe I am misinterpreting you here.

As an already frustrated user this question seems silly to me.

yeah that question is not fantastically helpful for us, I think maybe if we made it optional that would be better. it's probably more targeted for web-dev-y repos. keep in mind this was generated from a boilerplate service.

I tended to agree with Chris to streamline it, but then I looked more closely, and there's not a lot to get rid of.

I would put the environment stuff at the top. Users rarely think of it, it's quick to fill in, and too easy to overlook at the bottom.

SC version:
OS and version:
Qt version (optional):

Expected and actual behavior sections are necessary. Steps to reproduce, necessary. Error message, definitely necessary (and users often forget about that).

Context -- I have no idea what that means. Maybe "User impact"?

"Possible solution" is iffy for me. If a user is clever enough to think of a possible solution, she's probably clever enough to put it in a reasonable place.

Usually most of the questions are irrelevant after you've stated what the basic problem is.

It takes a lot of experience and practice to state a problem well.

@jamshark70 @crucialfelix I made a second pass over the templates; see what you think now. I removed the 'context' section (issue temp) and merged 'purpose' with 'context/motivation' (PR temp). Other small changes to wording; reordered sections of issue template. I understand there's a lot there, but aside from "possible solution" it is all necessary info. wouldn't be upset over removing 'possible solution' if you or anyone else wants to.

I'm definitely in support of the templates and the purpose in doing them. My point about conciseness is in order to reduce cognitive friction when people submit them.

"Possible solution" tends to come up in the discussion afterwards. If the person knows enough to submit a possible solution then they will suggest it right away without being asked. If it's just a bug then the person has to look at that and say "...uh... fix the bug ?"

"Possible solution" tends to come up in the discussion afterwards. If the person knows enough to submit a possible solution then they will suggest it right away without being asked.

OTOH, maybe new submitters can think about a solution or partial solution but don't realize how helpful it would be to verbalize it? I have gotten in the habit of leaving a comment trail when I do some research about an issue so that the next person who sees it can pick that up. Asking for that at the start could be valuable. And, if we have a template but don't include a part where we ask for it, maybe people will assume we don't care or don't want to know. What do you think about getting rid of the header and leaving in the comments?

And, if we have a template but don't include a part where we ask for it, maybe people will assume we don't care or don't want to know

I'm not sure that people think like that. If you ask every question rigidly then I think people only answer the questions and don't volunteer any more information after that.

I know that is the case for me when I submit bugs. If there are 5 questions and it's taken 20 minutes to fill in the ticket then they are more likely to just submit and run. Or just run.

That's the danger as I see it: exhaustion. Only ask for the essentials.

It's very similar to Surveys: https://www.surveymonkey.com/blog/2010/12/08/survey_questions_and_completion_rates/

Drop off rate increases with each additional question.

The incremental value of each question should be worth the possible drop in response rates.

I also don't think that a higher drop off rate leads to a higher quality of bug reports. Some of us are just really busy and don't have the time.

It certainly doesn't lead to a higher level of community involvement. Some people's issues may seem confused, but that is because they are confused. Many or most are not experienced programmers. Answering that question leads to them becoming more comfortable and engaging more.

Aight fine, I'll remove it

will the operating system matter in any of the many cases where the bug is (obviously for the person who submits) in the class library? It would seem a little silly to fill it in each time.

no, it won't matter in some cases, but yes, it will matter in many many cases.

James wrote

Users rarely think of it, it's quick to fill in, and too easy to overlook at the bottom.

and i agree

I'm moving this to backlog until #3075 is settled.

hm... maybe just omit the UniTest paragraph for now and ship the templates? I think they're worth to be seen...