Improve the quality of bugs and pull requests

[agaida]

We should provide Bug/PR templates per repo - could be helpful to get the needed informations.

https://github.com/blog/2111-issue-and-pull-request-templates
https://help.github.com/articles/creating-an-issue-template-for-your-repository/
https://help.github.com/articles/creating-an-issue-template-for-your-repository/

[tsujan]

Absolutely necessary! I think all of us missed that and finally @agaida discovered it.

[pmattern]

I agree we should really try to avoid useless reports like the aforementioned lxqt/pcmanfm-qt#412 which lead to this issue. This would be both in favor of us and the reporters which happen to spend time in something useless right now.
Not sure whether those templates are the best solution, though. Personally, I think they are a somewhat too rigid. They can never really cover all reports in a particular tracker which may result in not so helpful reports as well when users feel obliged to follow them nevertheless.
Could we by any chance create a dedicated wiki page which outlines what optionally matters in reports, trust the users they will make a reasonable choice and create a "template" which is pointing to this page?

[tsujan]

Personally, I think they are a somewhat too rigid. They can never really cover all reports in a particular tracker

Can you think of a report that can't be covered? An example?

[tsujan]

I mean with a design like this:

Component
Version
Expected behavior
Actual behavior
Steps to reproduce
Backtrace (for crashes)

Some entries can be left empty, of course. Feature requests and ideas are covered too, IMO.

[palinek]

We should make the template and we will see... IMO it will be used by reporters properly. If not, we will have the "wrong usage" cases and then can make further optimizations.

[pmattern]

@tsujan
I was referring to cases where the full-blown list of forms of a template is not needed. Feature requests are an example as well as malfunctions which have obviously been existing right from the beginning so naming versions or so does not make sense.

But this

We should make the template and we will see. [...] If not, we will have the "wrong usage" cases and then can make further optimizations.

Is certainly a way we can go.

[agaida]

@ALL - btw the templates are per repository - so we should not run into problems if we want specific informations about bugs/requests - We can use a standard template and modify it per repository if needed.

[tsujan]

@pmattern
Feauture requests can go to "Expected behavior" -- who cares about formality? ;)

The point is twofold, IMO: (1) The unexperienced user would know which info is relevant; and (2) the dev would have a clear problem to solve -- or no problem at all.

[mtasaka]

I agree we should really try to avoid useless reports like the
aforementioned lxqt/pcmanfm-qt#412 which lead to this issue.

I put a note here that this is perhaps a forwarded bug from Fedora project. Now Fedora uses "abrt", which catches segfault or so of applications automatically and reports such problems automatically. So in many cases (really many cases), when "abrt" catches some applications' segfault, users don't remember what they were doing, just saying "abrt caught crash, I don't know why".

[pmattern]

@mtasaka
All good and well. But look, even if so the OP of the said issue could simply have dropped a note like "Don't know what exactly I've been doing before the crash took place." The problem with that report was that some trace without any context, no information about OS in use, LXQt version and so on, is totally useless for us.

[agaida]

And therefore closed without much further processing - ok, i could remember that debug picture - at least i hope so ... and the outcome is a discussion about higher bug quality - so i guess if these procedures are established we will reject such bugs without processing. We have not enough manpower nor glass balls to waste time with happy bug guessing

Edit: Might be a nice game: Show me your dump and i guess the OS, LXQt version, Qt version - and the matching upstream bugs in all involved projects.

[agaida]

https://github.com/agaida/lxqt/issues/new

just copied one to push this forward - improvements needed, but i guess a good start -

@Esclapion @gilir @jleclanche @jubalh @luis-pereira @palinek @paulolieuthier @PCMan @pmattern @tsujan @yan12125

[yan12125]

Hmmm, what does "Environment name and version" mean?

[palinek]

just copied one to push this forward - improvements needed, but i guess a good start -

IMO we can use it "as is", good job 👍

[luis-pereira]

Anything that we put up, will need some iteration. IMO we can use it right now.
@agaida Being the templates per repository, will the issues created per repository ?

[agaida]

The templates are per repository - so if we put them into repos that are not handled in lxqt/issues we should not forget not to export them.

This also means - we adjust them per repository