From Fedora Project Wiki

(Moved the note about searching for duplicate bug reports into its own section and added a bit more on that topic.)
(Stylistic edits and a few syntax fixes, based on eawest's initial reivew.)
Line 7: Line 7:
''Audience:'' Linux users unfamiliar with bug reporting
''Audience:'' Linux users unfamiliar with bug reporting


''Assumptions:'' The user is running Fedora linux, has access to the internet, and generally understands how to use computer software.
''Assumptions:'' The user is running Fedora Linux, has access to the internet, and generally understands how to use computer software.


''Related Documents:'' [[BugsAndFeatureRequests]]
''Related Documents:'' [[BugsAndFeatureRequests]]


Note: This page is intended to more beginner friendly than [[BugsAndFeatureRequests]], and includes less technical information.  Hopefully, this page won't scare away a new user as the other might.
Note: This page is intended to be more beginner friendly than [[BugsAndFeatureRequests]], and includes less technical information.  Hopefully, this page won't scare away a new user as the other might.


''Lead Writer'': [[User:danielsmw]]
''Lead Writer'': [[User:danielsmw]]
Note: You seem to be duplicating http://fedoraproject.org/wiki/BugsAndFeatureRequests - RahulSundaram


----
----
Line 22: Line 19:
= How to File a Bug Report =
= How to File a Bug Report =


This page describes a procedure for reporting software bugs to Fedora developers.  A bug is generally defined as "an error, flaw, mistake, failure, fault or 'undocumented feature' in a computer program that prevents it from behaving as intended" ([http://en.wikipedia.org/wiki/Software_bug Wikipedia]).  While many organizations have now adopted Bugzilla as their bug tracking system, this page focuses specifically on the use of [https://bugzilla.redhat.com/ RedHat's Bugzilla system] for Fedora; however, other users may find the information helpful as well.
This page describes a procedure for reporting software bugs to Fedora developers.  A bug is defined as "an error, flaw, mistake, failure, fault or 'undocumented feature' in a computer program that prevents it from behaving as intended" ([http://en.wikipedia.org/wiki/Software_bug Wikipedia]).  This page focuses specifically on the use of [https://bugzilla.redhat.com/ RedHat's Bugzilla system] for Fedora.  Users may, however, find the information helpful for other Bugzilla implementations as well.
 
Bug reporting is an essential part of how Fedora improves software.  Without user feedback, many problems will remain unresolved, so learning to use the Bugzilla reporting tool is an important end-user skill.  With this in mind, remember that not everything you may use in Fedora is necessarily the responsibility of the Fedora project and its package maintainers.  If you are using [[ForbiddenItems]], for example, you should not submit a bug to the Fedora developers.  You should also not file a bug report with Fedora if you installed software from source instead of using Fedora's package manager.


Reporting bugs effectively is essential for the development and refinement of Fedora's many components.  Without user feedback, many bugs will lay unresolved, so learning to use the Bugzilla reporting tool can be an important end-user skill.  With this in mind, remember that not everything you may use in Fedora is necessarily the responsibility of the Fedora project and its package maintainers. If you are using [[ForbiddenItems]], for example, you should not submit a bug to the Fedora developers.
Fedora is an operating system, and the Fedora Project does not own or have responsibility for every program running on the computer. Please check the [[ForbiddenItems]] list before filing a bug report. Any bug in a program or utility listed on this page cannot be resolved by the Fedora Project team.


== Why do we file bugs? ==
== Why do we file bugs? ==


As a user, encountering bugs that hinder your work (or play) can often be frustrating, at best.  Oftentimes, ignoring bugs and just finding a different way to get your job done makes your immediate end-user experience more efficient.
As a user, encountering bugs that hinder your work (or play) can often be frustrating, at best.  Oftentimes, ignoring bugs and just finding a different way to get your job done makes your immediate end-user experience more efficient. In the long run, however, failing to report bugs means that problems you may have encountered will never be resolvedUnlike the experience many people have when reporting bugs to large software companies, open source users will find that software developers often reply to bug reports and engage the user personally though electronic means.
 
In the long run, however, failing to report bugs can cause the software you use to not live up to its full potential.  This may seem like a strange concept to users coming from a proprietary software backgroundBugs reported to large software corporations are influenced strongly by the market forces that sustain those companies.  So, for example, if fixing a bug won't produce a net financial gain, it probably won't be fixed.  Unlike these companies, programmers who develop open-source software (OSS) are free from market forces and usually develop software on their own time.  As such, they take particular pride in their software and strive to see it perfected for the end-user.


What does this mean for you?  It means that by properly reporting a bug, you can be sure that it will be paid attention to.  It may not be fixed immediately, but the developers who create the software you use care about issues that arise and have a desire to resolve those problems.  Unlike in a proprietary operating system where you might click "Send Bug Report" and never hear about it again, you should experience a result with OSS - be it resolution of the problem in an upcoming release or communication from the developers to work with you in resolving the issue.  It means that filing bugs is important, and you should do it whenever you have the chance.  It's just one way of giving back to the community.
What does this mean for you?  It means that by reporting a bug, you can be sure that it will be paid attention to.  It may not be fixed immediately, but the programmers who maintain the software you use are aware about issues that arise under your reported circumstances, and can work to resolve those problems for the future.


== Creating a Bugzilla Account ==
== Creating a Bugzilla Account ==
Bugzilla an open source bug tracking tool used for managing reports of issues, defects, and features by users.  Bugzilla is generally operated across a web interface.  To submit a bug using Bugzilla, you must first create a user account.
Bugzilla an open source bug-tracking tool used for managing reports of issues, defects, and features by users.  Bugzilla is usually accessed via a web interface - in other words, you use it [[User Guide - Accessing the Web| through your web browser]], and you will not need to download any new software.  To submit a bug using Bugzilla, you must first create a user account.
# Point your browser to [https://bugzilla.redhat.com/createaccount.cgi the account creation page].
# Point your browser to [https://bugzilla.redhat.com/createaccount.cgi the account creation page].
# Request an account using a legitimate email address.
# Request an account using your legitimate email address.
# Check your mail until you receive an account creation confirmation.
# Check your mail until you receive an account creation confirmation.
# Follow the link the email to continue account creation.  Fill in the requested fields, and sumbit the form.
# Follow the link the email to continue account creation.  Fill in the requested fields, and sumbit the form.
Note that if you do not act on the email confirmation within three days, it will expire.  In this case, you will need to start from the beginning again.
Note that if you do not act on the email confirmation within three days, it will expire.  In this case, you will need to start from the beginning again.


Once you have created an account, you can login with your email address and password.
Once you have created an account, you can login to Bugzilla with your email address and password.


== Gathering Information ==
== Gathering Information ==
Before reporting a bug, it is important to collect as much relevant information as possible.  As you collect this information, make sure you at least have the following:
Before reporting a bug, collect as much relevant information as possible.  As you collect this information, make sure you at least know the following:
* Whether or not the bug has already been reported
* Whether or not the bug has already been reported
* The name and version of the buggy software,
* The name and version of the buggy software,
* A qualitative description of what you were doing, and what you were trying to do, when the error occurred,
* A description of what you were doing, and what you were trying to do, when the error occurred,
* The operating system you are running, and
* The operating system you are running, and
* Your computer's architecture.
* Your computer's architecture.
Alone, however, this information is rarely comprehensive enough for developers to resolve the reported issue.  Consider reporting other information such as other running applications, any peripherals (printers, scanners, camera) that the software might have been interacting with, concurrent issues with other software (another program was malfunctioning at the same time), and the time and date at which the error occurred.  The more information the developer can see, the more clues he has as to the source of the malfunction.
Alone, however, this information is rarely enough for developers to resolve the reported issue.  Consider reporting other information such as other running applications, any peripherals (printers, scanners, camera) that the software might have been interacting with, concurrent issues with other software (another program was malfunctioning at the same time), and the time and date at which the error occurred.  The more information the developer can see, the more clues he has as to the source of the malfunction.


=== Avoiding Duplicate Bug Reports ===
=== Avoiding Duplicate Bug Reports ===


Sometimes, the most important information you can research is whether or not the bug has already been reported.  When the same bug is reported several times, developers are often weighed down with having to redundantly read all of them.  In the Bugzilla system, use the search feature to see if you can find an already-reported version of your bug.
Sometimes, the most important information you can research is whether or not the bug has already been reported.  When the same bug is reported several times in Bugzilla, developers are slowed down by having to read all of them redundantly.  In the Bugzilla system, use the search feature to see if you can find an already-reported version of your bug.
[[Image:BugSearch.png|frame|right|After clicking on the "Search Existing Bugs" link, you should see this simple bug-searching form.]]
[[Image:BugSearch.png|frame|right|After clicking on the "Search Existing Bugs" link, you should see this simple bug-searching form.]]
After you have logged into Bugzilla, look for your '''Most Common Actions''' pane on the left and click the "Search Existing Bugs" link (see figure under Filing a Bug Report).  One you have arrived at the search form, you can play with the different options and use various keywords to search for a bug that matches your issue.  The Advanced Search tab offers more flexibility, but is also very complex.  The simple form should be enough to verify the existence of a bug report.  You can select from various products, but you will probably want to select "Fedora" if you have an issue with either the Fedora operating system, one of its components, or one of its software packages.
After you have logged into Bugzilla, look for your '''Most Common Actions''' pane on the left and click the "Search Existing Bugs" link (see figure under Filing a Bug Report).  Once you have arrived at the search form, you can play with the different options and use various keywords to search for a bug that matches your issue.  The Advanced Search tab offers more flexibility, but is also very complex.  The simple form should be enough to verify the existence of a bug report.  Choose Fedora as the product unless you are confident that another choice is better here.


The importance of determining whether or not a bug has already been filed cannot be stressed enough.  If in doubt, it is always better to file a bug than to ignore it; however, developers can be slowed down by the weight of duplicate bug reports, so ensure that you conduct a thorough search before filing yours.
The importance of determining whether or not a bug has already been filed cannot be stressed enough.  If in doubt, it is always better to file a bug than to ignore it; however, developers can be slowed down by the weight of duplicate bug reports, so ensure that you conduct a thorough search before filing yours.
Line 63: Line 60:
=== Finding Common Information ===
=== Finding Common Information ===


Your bug report will almost always contain the information listed above, although more often than not additional information will be needed.  Nonetheless, it is good to know ways to determine commonly needed data about your bug.
Your bug report will almost always contain the information listed above. More often than not, though, additional information will be needed.  It is important to know ways to determine frequently needed data about your bug. This might involve using a terminal.  To open a terminal in Gnome, click ''Applications->System Tools->Terminal''. 
; Software Version : The version often be found within the ''Help'' menu in a graphical program.  For a console utility, the program's man page should tell you what flag to use to print out the version (oftentimes, this involves typing <code>--version</code> after the command).  
; Software Version : The version often be found within the ''Help'' menu in a graphical program.  For a console utility, the program's man page should tell you what flag to use to print out the version (oftentimes, this involves typing <code>--version</code> after the command).  To view the man page, type <code>man program</code>, where <code>program</code> is the software you are trying to check.
; Operating System : There are many ways to determine the operating system you are running, but running <code>uname -sr</code> is one way of doing it.
; Operating System : There are many ways to determine the operating system you are running, but running <code>uname -sr</code> in a terminal is one way to do it.
; Architecture : Two of many ways to determine the architecture of your processor are with <code>uname -p</code> and <code>arch</code>.
; Architecture : Two of many ways to determine the architecture of your processor are with <code>uname -p</code> and <code>arch</code>.
To run any of the commands above, such as <code>uname</code>, just type your full command in the terminal window and press '''[ Enter ]'''.


=== Reproducing Errors ===
=== Reproducing Errors ===


Oftentimes, the information you send the developer just isn't enough.  In order to understand what was going on "under the hood", so to speak, the developer will need to reproduce the error independently.  Therefore, be ready to provide the developer with a step-by-step procedure with which he should be able to reproduce the error.  If you feel that there the error is only related to the program, then a good place to start might be the initial execution of that program.
Oftentimes, the information you send the developer just isn't enough.  In order to understand what was going on "under the hood", so to speak, the developer will need to reproduce the error on his own.  Therefore, be ready to provide the developer with step-by-step instructions on how he should be able to reproduce the error.  If you feel that there the error is only related to the program, then a good place to tell him to start might simply be running that program.


<!--
<!--
Line 78: Line 77:
First, I started the program by clicking on it in the Applications menu in GNOME.  Then, I created a new document, changed the default text color to red, and went clicked the print button on the taskbar.  That's when the program froze.
First, I started the program by clicking on it in the Applications menu in GNOME.  Then, I created a new document, changed the default text color to red, and went clicked the print button on the taskbar.  That's when the program froze.
-->
-->
While a pixel-by
 
pixel description of how you clicked on things is probably not necessary, it is important that you describe the method through which you did something.  For example, a program may have several different methods of printing a document: a keyboard shortcut, a menu item, or a taskbar button, perhaps.  You need to document which method produced the error.
While a pixel-by-pixel description of how you clicked on things is probably not necessary, it is important that you describe the basic outline of how you made the bug appear.  For example, a program may have several different methods of printing a document: a keyboard shortcut, a menu item, or a taskbar button, perhaps.  You need to tell the developer which method produced the error.


== Filling Out a Bug Report ==
== Filling Out a Bug Report ==
[[Image:Bugzilla_Actions.png|frame|right|The common actions pane at bugzilla.redhat.com.  Click "Enter a new bug report" to begin.]]
[[Image:Bugzilla_Actions.png|frame|right|The common actions pane at bugzilla.redhat.com.  Click "Enter a new bug report" to begin.]]
Once you have successfully logged into the Bugzilla system and collected the necessary data, you can proceed with filing the report.  Again, remember to make sure your bug hasn't already been filed by somebody else.
Once you have successfully logged into the Bugzilla system and collected the necessary data, you can start to file the report.  Again, remember to make sure your bug hasn't already been filed by somebody else.


After logging in at https://bugzilla.redhat.com, you should see a side pane with common actions.  Click on "Enter a new bug report".
After logging in at https://bugzilla.redhat.com, you should see a side pane with common actions.  Click on "Enter a new bug report".


After starting your bug report, you will be prompted to choose the project your bug is in.  If you experience a bug using Fedora Linux, then you should probably click "Fedora" here.  The next menu will present options for categories within the project you selected.  If you found a bug in some software, you should probably just click "Fedora".  Each category has a short caption to help you choose one.  If you find an error in the documentation, for example, you may want to click "Fedora Documentation" instead.
After starting your bug report, you will be prompted to choose the project your bug is in.  If you are experiencing a bug using Fedora Linux, then you should probably click "Fedora" here.  The next menu will present options for categories within the project you selected.  If you found a bug in some software, you should probably just click "Fedora".  Each category has a short caption to help you choose one.  If you find an error in the documentation, for example, you may want to click "Fedora Documentation" instead.


If, for some reason, you really just can't decide where your bug belongs, don't give up.  Just submit it somewhere, and the developers will reassign it to the appropriate project if necessary.
If, for some reason, you really just can't decide where your bug belongs, don't give up.  Just submit it somewhere, and the developers will reassign it to the appropriate project if necessary.
Line 96: Line 95:


=== Guided Form ===
=== Guided Form ===
The guided form provides an easy step-by-step method for filing bugs.  By default, however, you will see the standard form.  To switch to the guided form, click "Guided" in the second sentence on the page ("You may also use the Guided bug entry page for a easier step by step method. ").  The guided form involves three steps.
The guided form provides an easy step-by-step method for filing bugs.  By default, however, you will see the standard form.  To switch to the guided form, click "Guided" in the second sentence on the page ("You may also use the Guided bug entry page for a easier step by step method. ").  The guided form involves three steps.


First, determine if your bug has already been reported.  The first step will allow you to search through bugs on record so you can ensure that your bugs is not already registered in Bugzilla.
First, determine if your bug has already been reported.  The first step will allow you to search through bugs on record so you can ensure that your bugs is not already registered in Bugzilla.
Line 102: Line 101:
Next, you need to give detailed information about your bug. Fill in each of the queries:
Next, you need to give detailed information about your bug. Fill in each of the queries:


; Component : Choose the name of the software that is giving you trouble.  Depending on your bug, this might also be a documentation file or other component of Fedora.
; Component : Choose the name of the software that is giving you trouble.  Depending on your bug, this might also be a software application, a documentation file, or another component of Fedora.
; Hardware Platform : This is your architecture that we determined earlier.  If, for some reason, you are unsure of your platform, you can probably choose i386; however, make every effort to be sure of your architecture if you can.
; Hardware Platform : This is your architecture that we determined earlier.  If, for some reason, you are unsure of your platform, you can probably choose i386; however, make an effort to be sure of your architecture if you can.
; URL : This is an optional field, and you can leave it out unless it applies to you.
; URL : This is an optional field, and you can leave it out unless it applies to you.
; Summary : Fill in a short, one sentence description of the problem.  For example, "Saving file in .tiff format causes program to exit."
; Summary : Fill in a short, one sentence description of the problem.  For example, "Saving file in .tiff format causes program to exit."
; Details : This is your long version of the issue.  Be as specific as possible.  Make sure to give a rational, complete depiction of the problem; saying "The print button is broken" is not sufficient.
; Details : This is your long version of the issue.  Be as specific as possible.  Make sure to give a rational, complete depiction of the problem; saying "The print button is broken" does not describe the problem enough.
; Reproducibility : This is a very important field.  Does this happen every time you follow some procedure?  Does it only happen on Tuesdays?  Was it only once?
; Reproducibility : This is a very important field.  Does this happen every time you follow some procedure?  Does it only happen on Tuesdays?  Was it only once?
; Steps to Reproduce : As discussed earlier, provide the steps you followed to reach the bug.  If the problem cannot be reproduced, say so in "Reproducibility" and give the steps to the best of your memory.
; Steps to Reproduce : As discussed earlier, provide the steps you followed to reach the bug.  If the problem cannot be reproduced, say so in "Reproducibility" and give the steps to the best of your memory.
; Actual Results : What happened when you reached the bug?
; Actual Results : What happened when you reached the bug?
; Expected Results : What do you think should have happened?
; Expected Results : What do you think was supposed to happen?
; Additional Information : If there's anything else you feel the developer need to know, you can put it here.  This might be an error message from console output, or it might be the model of your camera that was connected when the bug occurred.
; Additional Information : If there's anything else you feel the developer need to know, you can put it here.  This might be an error message from console output, or it might be the model of your camera that was connected when the bug occurred.
; Severity : When reporting the severity of the issue, be reasonable.  Try to be objective.  Remember that, although the error may inconvenience you, it may not actually be a big deal.  Each severity level has a caption that should help you decide.
; Severity : When reporting the severity of the issue, be reasonable.  Try to be objective.  Remember that, although the error may inconvenience you, it may not actually be a big deal.  Each severity level has a caption that should help you decide.

Revision as of 15:41, 6 February 2009

This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

Documentation Summary:

Purpose: To describe steps for reporting bugs in language comfortable to novices.

Audience: Linux users unfamiliar with bug reporting

Assumptions: The user is running Fedora Linux, has access to the internet, and generally understands how to use computer software.

Related Documents: BugsAndFeatureRequests

Note: This page is intended to be more beginner friendly than BugsAndFeatureRequests, and includes less technical information. Hopefully, this page won't scare away a new user as the other might.

Lead Writer: User:danielsmw


How to File a Bug Report

This page describes a procedure for reporting software bugs to Fedora developers. A bug is defined as "an error, flaw, mistake, failure, fault or 'undocumented feature' in a computer program that prevents it from behaving as intended" (Wikipedia). This page focuses specifically on the use of RedHat's Bugzilla system for Fedora. Users may, however, find the information helpful for other Bugzilla implementations as well.

Bug reporting is an essential part of how Fedora improves software. Without user feedback, many problems will remain unresolved, so learning to use the Bugzilla reporting tool is an important end-user skill. With this in mind, remember that not everything you may use in Fedora is necessarily the responsibility of the Fedora project and its package maintainers. If you are using ForbiddenItems, for example, you should not submit a bug to the Fedora developers. You should also not file a bug report with Fedora if you installed software from source instead of using Fedora's package manager.

Fedora is an operating system, and the Fedora Project does not own or have responsibility for every program running on the computer. Please check the ForbiddenItems list before filing a bug report. Any bug in a program or utility listed on this page cannot be resolved by the Fedora Project team.

Why do we file bugs?

As a user, encountering bugs that hinder your work (or play) can often be frustrating, at best. Oftentimes, ignoring bugs and just finding a different way to get your job done makes your immediate end-user experience more efficient. In the long run, however, failing to report bugs means that problems you may have encountered will never be resolved. Unlike the experience many people have when reporting bugs to large software companies, open source users will find that software developers often reply to bug reports and engage the user personally though electronic means.

What does this mean for you? It means that by reporting a bug, you can be sure that it will be paid attention to. It may not be fixed immediately, but the programmers who maintain the software you use are aware about issues that arise under your reported circumstances, and can work to resolve those problems for the future.

Creating a Bugzilla Account

Bugzilla an open source bug-tracking tool used for managing reports of issues, defects, and features by users. Bugzilla is usually accessed via a web interface - in other words, you use it through your web browser, and you will not need to download any new software. To submit a bug using Bugzilla, you must first create a user account.

  1. Point your browser to the account creation page.
  2. Request an account using your legitimate email address.
  3. Check your mail until you receive an account creation confirmation.
  4. Follow the link the email to continue account creation. Fill in the requested fields, and sumbit the form.

Note that if you do not act on the email confirmation within three days, it will expire. In this case, you will need to start from the beginning again.

Once you have created an account, you can login to Bugzilla with your email address and password.

Gathering Information

Before reporting a bug, collect as much relevant information as possible. As you collect this information, make sure you at least know the following:

  • Whether or not the bug has already been reported
  • The name and version of the buggy software,
  • A description of what you were doing, and what you were trying to do, when the error occurred,
  • The operating system you are running, and
  • Your computer's architecture.

Alone, however, this information is rarely enough for developers to resolve the reported issue. Consider reporting other information such as other running applications, any peripherals (printers, scanners, camera) that the software might have been interacting with, concurrent issues with other software (another program was malfunctioning at the same time), and the time and date at which the error occurred. The more information the developer can see, the more clues he has as to the source of the malfunction.

Avoiding Duplicate Bug Reports

Sometimes, the most important information you can research is whether or not the bug has already been reported. When the same bug is reported several times in Bugzilla, developers are slowed down by having to read all of them redundantly. In the Bugzilla system, use the search feature to see if you can find an already-reported version of your bug.

After clicking on the "Search Existing Bugs" link, you should see this simple bug-searching form.

After you have logged into Bugzilla, look for your Most Common Actions pane on the left and click the "Search Existing Bugs" link (see figure under Filing a Bug Report). Once you have arrived at the search form, you can play with the different options and use various keywords to search for a bug that matches your issue. The Advanced Search tab offers more flexibility, but is also very complex. The simple form should be enough to verify the existence of a bug report. Choose Fedora as the product unless you are confident that another choice is better here.

The importance of determining whether or not a bug has already been filed cannot be stressed enough. If in doubt, it is always better to file a bug than to ignore it; however, developers can be slowed down by the weight of duplicate bug reports, so ensure that you conduct a thorough search before filing yours.

Finding Common Information

Your bug report will almost always contain the information listed above. More often than not, though, additional information will be needed. It is important to know ways to determine frequently needed data about your bug. This might involve using a terminal. To open a terminal in Gnome, click Applications->System Tools->Terminal.

Software Version
The version often be found within the Help menu in a graphical program. For a console utility, the program's man page should tell you what flag to use to print out the version (oftentimes, this involves typing --version after the command). To view the man page, type man program, where program is the software you are trying to check.
Operating System
There are many ways to determine the operating system you are running, but running uname -sr in a terminal is one way to do it.
Architecture
Two of many ways to determine the architecture of your processor are with uname -p and arch.

To run any of the commands above, such as uname, just type your full command in the terminal window and press [ Enter ].

Reproducing Errors

Oftentimes, the information you send the developer just isn't enough. In order to understand what was going on "under the hood", so to speak, the developer will need to reproduce the error on his own. Therefore, be ready to provide the developer with step-by-step instructions on how he should be able to reproduce the error. If you feel that there the error is only related to the program, then a good place to tell him to start might simply be running that program.


While a pixel-by-pixel description of how you clicked on things is probably not necessary, it is important that you describe the basic outline of how you made the bug appear. For example, a program may have several different methods of printing a document: a keyboard shortcut, a menu item, or a taskbar button, perhaps. You need to tell the developer which method produced the error.

Filling Out a Bug Report

The common actions pane at bugzilla.redhat.com. Click "Enter a new bug report" to begin.

Once you have successfully logged into the Bugzilla system and collected the necessary data, you can start to file the report. Again, remember to make sure your bug hasn't already been filed by somebody else.

After logging in at https://bugzilla.redhat.com, you should see a side pane with common actions. Click on "Enter a new bug report".

After starting your bug report, you will be prompted to choose the project your bug is in. If you are experiencing a bug using Fedora Linux, then you should probably click "Fedora" here. The next menu will present options for categories within the project you selected. If you found a bug in some software, you should probably just click "Fedora". Each category has a short caption to help you choose one. If you find an error in the documentation, for example, you may want to click "Fedora Documentation" instead.

If, for some reason, you really just can't decide where your bug belongs, don't give up. Just submit it somewhere, and the developers will reassign it to the appropriate project if necessary.

Once you have selected your bug's category, you will need to fill out the actual report. There are two methods for doing this; you can use the standard form or the guided form. The standard form is less verbose but easier to use if you know what you're doing. The guided form is recommended for new users.

Either way, make sure you have all the information you collected earlier, and start to fill in the fields.

Guided Form

The guided form provides an easy step-by-step method for filing bugs. By default, however, you will see the standard form. To switch to the guided form, click "Guided" in the second sentence on the page ("You may also use the Guided bug entry page for a easier step by step method. "). The guided form involves three steps.

First, determine if your bug has already been reported. The first step will allow you to search through bugs on record so you can ensure that your bugs is not already registered in Bugzilla.

Next, you need to give detailed information about your bug. Fill in each of the queries:

Component
Choose the name of the software that is giving you trouble. Depending on your bug, this might also be a software application, a documentation file, or another component of Fedora.
Hardware Platform
This is your architecture that we determined earlier. If, for some reason, you are unsure of your platform, you can probably choose i386; however, make an effort to be sure of your architecture if you can.
URL
This is an optional field, and you can leave it out unless it applies to you.
Summary
Fill in a short, one sentence description of the problem. For example, "Saving file in .tiff format causes program to exit."
Details
This is your long version of the issue. Be as specific as possible. Make sure to give a rational, complete depiction of the problem; saying "The print button is broken" does not describe the problem enough.
Reproducibility
This is a very important field. Does this happen every time you follow some procedure? Does it only happen on Tuesdays? Was it only once?
Steps to Reproduce
As discussed earlier, provide the steps you followed to reach the bug. If the problem cannot be reproduced, say so in "Reproducibility" and give the steps to the best of your memory.
Actual Results
What happened when you reached the bug?
Expected Results
What do you think was supposed to happen?
Additional Information
If there's anything else you feel the developer need to know, you can put it here. This might be an error message from console output, or it might be the model of your camera that was connected when the bug occurred.
Severity
When reporting the severity of the issue, be reasonable. Try to be objective. Remember that, although the error may inconvenience you, it may not actually be a big deal. Each severity level has a caption that should help you decide.
Security
If you have identified a security-compromising problem, it needs to be noted here. These can often be serious issues.
In guided mode, there is no button for creating an attachment. If you have a screenshot, error log, stack trace, or any other important information you want to submit, you'll have to use the "Create a new Attachment" link on the bug after you submit it.

Finally, click submit, and check your email periodically for updates on the problem or clarification questions from developers.

Further Reading