A bug report means something is broken, preventing a normal/typical use of NethServer.
Check if you are using the latest version
Please check if you are using the latest release. If not, upgrade and check if the bug still exists.
Check if the bug is known
Please check whether the bug you are experiencing is already documented in the issue tracker or in the bug category. If it’s already documented, you may click “watch” to follow any developments. If your bug is different than any others recorded in the issue tracker:
- Create a new topic into the Bug category
If the bug is on the project infrastructure (not NethServer itself)
- The www site is down
- Problems with mirrors
- Problems with packages.nethserver.org
- Problems with discourse (this forum)
Please open in the #bug category adding the tag “infrastructure” to the topic
File each issue separately
If you have multiple issues, it is better to file them separately so they can be tracked easier.
Choose a good title for the bug report
BE BRIEF. A good title should quickly and uniquely identify a bug report. It should explain the problem, not your suggested solution.
Good: “Canceling a File Copy dialog crashes File Manager”
Bad: “Software crashes”
Bad: “Problem with content filter”
Bad: “Issue with calendar”
Bad: “Browser should work with my website”
After submitting the bug, it’s possible to improve the title.
Steps to reproduce the bug
A bug report requires clear instructions so that others can consistently reproduce it. Many bugs require some experimentation to find the exact steps that cause the problem you are trying to report. If you aren’t able to discover these, try obtaining some help on community instead.
A good set of instructions includes a numbered list that details each button press, or menu selection.
Tell us what should happen
Tell us what happens instead
Have you got any error from the GUI? Attach a screenshot
Adding images is a quick way to add context to your bug. Consider adding an image even if you also have a video.
Highlight the area(s) of interest in your image.
Paste the image files directly to the report
Have you looked to the log?
Check /var/log/messages or/and any other relevant log. If you don’t know which log check ask to the community
- Be specific. If you can do the same thing two different ways, state which one you used. “I selected Load” might mean “I clicked on Load” or “I pressed Alt-L”. Say which you did. Sometimes it matters.
- Be verbose Give more information rather than less. If you say too much, the programmer can ignore some of it. If you say too little, they have to come back and ask more questions. One bug report I received was a single sentence; every time I asked for more information, the reporter would reply with another single sentence. It took me several weeks to get a useful amount of information, because it turned up one short sentence at a time.
- Be careful of pronouns. Don’t use words like “it”, or references like “the window”, when it’s unclear what they mean. Consider this: “I started FooApp. It put up a warning window. I tried to close it and it crashed.” It isn’t clear what the user tried to close. Did they try to close the warning window, or the whole of FooApp? It makes a difference. Instead, you could say “I started FooApp, which put up a warning window. I tried to close the warning window, and FooApp crashed.” This is longer and more repetitive, but also clearer and less easy to misunderstand.
- Read what you wrote. Read the report back to yourself, and see if you think it’s clear. If you have listed a sequence of actions which should produce the failure, try following them yourself, to see if you missed a step.