Those are the basics for bug reporting, as I understand them. Please feel free to ask any questions on bugs (basic level, not advanced!) and I will endeavour to answer them (or get some one from the bug-squad to do so).

Usually, when a bug is marked "Private" there's some good reason for it. With a lot of segfault (crash) bugs I see, a lot of them get marked as private, either because they contain information that *could* be private or could identify your system, or similar reasons

Typically, I see this with bugs which have core dumps or tracebacks which could contain information to identify someone: passwords, account numbers, etc. fall in the category of information that needs to be "removed" from the bug before it goes to a public view.

Those private bugs are therefore exactly what they are: hidden from the public eye until someone's gotten to it and actually looked through to see if there's anything that needs removal on those bugs, and then we usually make the bug visible after such things.

you will at the top a link to report a bug against the test case. This is for any spelling mistakes we make and if a test case is not following the order of carrying it out that you are seeing so that they can be edited and corrected.

first of all I’d like to apologise for the misleading title of this talk, I am not just going to talk about what to do to follow up on your bugs, but also about how to raise good bugs in the first place

Think of the developer/maintainer as your customer: give him all he needs without him having to ask for it. After all, a happy customer improves the odds of a productive and mutually beneficial relationship

* Test environment: What is your hardware? Is the bug be hardware specific? Where you in an X session? What else was running on your machine? what other software is running that might interact with the software under test?

1) security bug - e.g. if the software is leaking private/secure data, or allow crashing the whole OS (Denial-of-service), or... - this should be reported as a security issue and ping the security team in the process. In some cases this type of bug shouldn’t be made public straight away, to avoid putting people affected by the vulnerability at greatest risk.

The developer is the expert on the software code, but you are the expert on how the software really behaves under the conditions you are testing, so you are going to be required to provide feedback as the developer explores the problem.

Make sure to test their solution so that you are satisfied it meets your expectations, or reopen the bug if not (it is easier for the developer to deal with a second fix straight away than after two weeks).