CommunityBugReporting
135
Comment:
|
3030
skeleton
|
Deletions are marked like this. | Additions are marked like this. |
Line 3: | Line 3: |
''Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.'' * '''Launchpad entry''': https://launchpad.net/distros/ubuntu/+spec/community-bug-reporting * '''Products affected''': malone, ubuntu-website |
|
Line 4: | Line 9: |
[:LoCoTeamsUDSMVSpecs] | |
Line 5: | Line 11: |
Go back to the main [:LoCoTeamsUDSMVSpecs] page | == Summary == |
Line 7: | Line 13: |
Details coming soon. | == Rationale == Effective bug reporting is central to the success of Ubuntu or any other project. Right now some people submit bug reports, but many enthusiasts and users still don't. We want to develop a culture where bug reporting is a natural process that enthusiasts can do. We are unlikely to get regular users (such as the average dad) to submit bugs, but the huge community of Ubuntu enthusiasts are ideally placed to test and submit bugs. Currently the QA team == Use cases == == Scope == == Design == == Implementation == === Code === === Data preservation and migration === == Unresolved issues == Testing is the key here. If we want future versions of Ubuntu to work as best as possible, we need users to test hardware support ad features, and submit bugs when things don't work. This needs to happen ''before'' release where possible.. This spec is intended to discuss ideas that can make this process easier. For this to happen we should work with the documentation, bug and marketing teams where possible. I think it would make sense to put together a team of people comprising people from these teams to coordinate how this works. Things to think about: == Better documentation == Bug reports are useful, but well written bug reports are really what we want. We want users to know what to test, where to go and what kind of information to put into a bug report. We need two types of documentation here: * Quickshot guides - simple, concise, attractive guides to doing things. These guides should not only be easy to read and step by step, but be attractive and easy to find. * General manual style docs - details of the bug reporting process. Right now we have the latter, and partially the former, but we need to get the quickshot guides to ''everyone'' in the community. == Awareness Campaign == We need to market the fact that bug reporting is a fairly simple process and it ''really does help the community''. For this we really need an awareness campaign. == Making it happen == Lets make this happen. To do this I recommend we take a representative from each team to coordinate how this project is run. Each representative can consult their team to satisfy their part of the project. == Comments == UbuntuDemon : IMHO an integrated ubuntuforums / launchpad login would be very nice. Often users with problems go to the forums. When we (the forum users) think the problem is a bug the user who reported the problem should be able to report this bug on launchpad/malone with as little effort as possible. |
Community Bug Reporting
Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.
Launchpad entry: https://launchpad.net/distros/ubuntu/+spec/community-bug-reporting
Products affected: malone, ubuntu-website
Include(LoCoMenuHeader) [:LoCoTeamsUDSMVSpecs]
Summary
Rationale
Effective bug reporting is central to the success of Ubuntu or any other project. Right now some people submit bug reports, but many enthusiasts and users still don't. We want to develop a culture where bug reporting is a natural process that enthusiasts can do. We are unlikely to get regular users (such as the average dad) to submit bugs, but the huge community of Ubuntu enthusiasts are ideally placed to test and submit bugs.
Currently the QA team
Use cases
Scope
Design
Implementation
Code
Data preservation and migration
Unresolved issues
Testing is the key here. If we want future versions of Ubuntu to work as best as possible, we need users to test hardware support ad features, and submit bugs when things don't work. This needs to happen before release where possible..
This spec is intended to discuss ideas that can make this process easier. For this to happen we should work with the documentation, bug and marketing teams where possible. I think it would make sense to put together a team of people comprising people from these teams to coordinate how this works.
Things to think about:
Better documentation
Bug reports are useful, but well written bug reports are really what we want. We want users to know what to test, where to go and what kind of information to put into a bug report. We need two types of documentation here:
- Quickshot guides - simple, concise, attractive guides to doing things. These guides should not only be easy to read and step by step, but be attractive and easy to find.
- General manual style docs - details of the bug reporting process.
Right now we have the latter, and partially the former, but we need to get the quickshot guides to everyone in the community.
Awareness Campaign
We need to market the fact that bug reporting is a fairly simple process and it really does help the community. For this we really need an awareness campaign.
Making it happen
Lets make this happen. To do this I recommend we take a representative from each team to coordinate how this project is run. Each representative can consult their team to satisfy their part of the project.
Comments
UbuntuDemon : IMHO an integrated ubuntuforums / launchpad login would be very nice. Often users with problems go to the forums. When we (the forum users) think the problem is a bug the user who reported the problem should be able to report this bug on launchpad/malone with as little effort as possible.
LoCoTeamsUDSMVSpecs/CommunityBugReporting (last edited 2008-08-06 16:22:05 by localhost)