Text for Bugreport info sheet.

File Metadata

Author
jensreuterberg
Created
Sep 19 2016, 1:04 PM

Text for Bugreport info sheet.

1) Download Test Iso and Install, run from USB or Install in a Virtual Machine (links to how to do all three)
[Link to: The best way is to use an up to date ISO for example from KaOS (link to ISO), KDE Neon Dev Unstable (link to ISO), Opensuse Krypton/Argon(link to ISO) install it either directly on the machine or in a virtual machine [link to info about VM's] - you can also test it from a live USB but in those cases stuttering and small glitches and delays will be normal)

2) If you find something that looks odd, a visual glitch, a program that doesn't start, something takes way longer than it should go to bugzilla and prepare to report the bug [adress to bugzilla]

3) Fill in your KDE Account, if you don't have one here is where get one [link to KDE accounts]

4) Search for the Bug, someone may already have done a bug on this particular issue. It helps to narrow it down by searching per area [here is an intro to each area]
[The Intro to each area I would LOVE to write out entirely but feel less in control over]

5) If you find several bugs of the same thing this is a good time to do some triage [something about how to flag stuff as duplicates]

6) Write down whats relevant to the bug, go for factual instead of as if you where writing to a person. Less is more but make sure to include all critical data. Sometimes you may be a bit wrong in the beginning and if you are that's ok. Better to write a bug and learn how to do it than not at all!

7) Keep tabs on the bug! You will get emails concerning changes to it and may get further questions. Remember to reply and remember to assume good faith in the other people. The devs wanna fix the bug but as the language is made to be factual instead of discussion-like they may sound a bit cropped in tone. Don't worry their not angry, just trying to fix stuff 
Chapters:
_____________________________________________________
Chapter I: Introduction to Bugs, reporting and triage
Why is it so terribly important to do test for bugs, report them and triage the bugs already reported and what does it mean when someone asks you to do either of these things? The goal with this short text is to give you, the reader a cursory and simple introduction to the subject so that you too can help and support your favorite project with this one of the most critical parts of software development.
We will in the course of this text, explain what the terms mean, how to test for bugs in newly released software, how to report them properly and how to triage bugs already reported.
First of all lets look at the reasons why this subject keeps recurring: Developers, programmers, have a ton of things on their plate - they work to create the software we all love and use. The problem is that with the growth of Linux and the growing numbers of KDE and Plasma users as well as the age of a project creates more and more material to keep tabs on and ensure that its running. On the one hand the developers need to create new things, or for example port things from earlier releases, but on the other as maintainers they also need to ensure that the things already create run smoothly by fixing bugs.
One of the basic ways to do this is to ensure that the bugs are not only tested to ensure that they are in fact bugs, or create fixes for these bugs, but to make sure that the list of bugs only contains relevant information. Bugs can be incorrectly reported, reported in the wrong area of the list, no longer relevant due to fixes or changes, or duplicates of other bugs.
These "false bugs reports" in the list of bugs cause issues for the developer or maintainer as the main tool they rely on to make sure that the software they made run smoothly is not littered with incorrect information.
With the growth of the userbase the number of reported bugs, either through automated systems or individual reports grow - but the number of developers remain closer to the original number. Due to the fact that very few know how to do bug testing and triaging this means that the developers have to themselves go through the buglists and look for duplicates and ensure that the buglist is relevant and somewhat representative of needed work.
As users, by learning this, we can quickly and easily take a few minutes per day and go through the bug list - rinse out duplicates, perhaps test if we can duplicate a bug, add more information or report a bug as something that should be removed. By doing this we elleviate pressure from the developers and maintainers and let them focus on creating new software or make our current software even more stable and easy to use.
It is one of the most needed and critical ways we as users can take an active and appreciated role in the projects we love.
---------------------------
TL;DR BOX: A messy bug list is one of the biggest time sinks for developers as they have to now focus on that instead of programming and development of software. By helping out, you literally create more hours to work in for the developers.
---------------------------
_____________________________________________________
Chapter II: Introduction to the Terminology
What to write about:
Triage, Bug, Product, Component [COMP], Assignee, Status Unconfirmed, Confirmed, Assigned and Reopened. Backlog. Importance. Target Milestone.
_____________________________________________________
Chapter III: How to handle Bugzilla
What to write about:
[KDE Accounts],
[Bugzilla],
[Areas in bugs.kde.org].
"Why are everyone so rude?" is something some users often wonder. People seem curt and almost rude to each other in bug reports and they will seem equally short in speaking to you. Don't think this is rudeness. This is simply routine and trying to be effective. By keeping the language clear, factual and technical bug fixing is simply easier for all involved.
Assume good intend from all - if someone says something that you think is rather cut and short, think that the person who says it is probably dealing with his or her 20th bug today and wants to fix this to get onto other things. Speed, accuracy and clarity are all relevant goals and they never mean that the person trying to achieve them is attempting to be rude towards you.
(sidenote: IF someone is rude, racist, sexist, abrasive or insulting and more - please say so clearly and call that person out. Often it is not intended as such, but call it out anyway)
_____________________________________________________
Chapter IV: How to Report bugs
Testing for bugs in new software is also very relevant. Linux exists on a ton of different kinds of hardware and in different variations and testing all of them would be practically as well as economically impossible to developers. So as a user you can easily help out by downloading a test ISO for the new version of Plasma, compile an application from git or simply use it and keep an eye out for glitches and odd little things.
To test Plasma or upcoming KDE software we suggest downloading an ISO that closely follows development. Be careful though as they can often be unstable. KaOS, KDE Neon Dev Unstable and Opensuse Argon/Krypton are all examples of good distros to choose from should you want to test this.
It can be prudent if you don't want to install it directly to your machine to either use a Virtual Machine, or running it directly from the Live USB - just remember that those two methods can cause visual glitches or slow starts as they don't use your entire computer to work.
[How to use a Virtual Machine for testing] [How to Create and use a live USB]
Now of course we are often noticing odd little behaviours in the apps we already have installed and its always good to keep an eye out for that. Even if something isn't brand new, as long as it's actively maintained, it will have a maintainer that will care for that bugreport.
When you report a bug there are some things to keep in mind: first off be brief and correct without leaving things out. To do this ensure that you first off all report what happened, how it happened, how often it happens and how it can be reproduced. Avoid flowery language and try to be as exact and clear as possible. The developer don't need to know if you're angry or what you did when you encountered this bug, or for that matter that you're happy or anything beyond the practical technical information on what happened, how it happened, how often it recurrs and how it can be reproduced.
For example: every time you search in the Application Launcher, plasma crashes making it flicker out and then back in as it restarts.
What you do then is to test if it happens every time you search or only for certain things, then you test if the search has to be a certain length or happened enough times in a row for Kwin to crash.
To report it you log into bugs.kde.org and find the correct area and Product to report it as mentioned above (How to Handle Bugzilla and Terminology).
Then you search for the bug, perhaps someone else has already reported it? If so fill in further information if its lacking or be sure to say that you too where affected and what seperates your situation (the hardware or distro you are using if it is different) from the original reporters.
If at this time you find several bugs with the same issue, take the one that is with the most amount of relevant information and report the others as duplicates (see below Chapter VI How to Triage Bugs)
[Screenshot of a Bug Report for this fictional scenario]
Fill in whether it is reproducible and at what degree. So essentially how often it happens under these circumstances that you test it) and steps to reproduce.
Then write in what happened, in this case "Kwin Crashed" and finally what you expected to happen "I found the app I was searching for". It may seem redundant at that time to write it out, but please do - by keeping a constant and clear form the report is easier to read when you have to read through several a day.
When you've finished reporting the bug, remember to keep a watch out for replies in your inbox. Many think that as their part is now done they can safely ignore it, but that is not true.
Questions, suggestions for fixes or other details may be added and require for you to reply and if you don't the bug simply will not have that good a chance of being fixed.
_____________________________________________________
Chapter V: Automated Bug reports
[introduction to the automatic bug reports]
_____________________________________________________
Chapter VI: How to Triage bugs
What to look for, how to look for it, how to test for it and how to report changes
_____________________________________________________
Chapter VII: Why this is important to us all and thank you!