Get Involved/Extra Mile
Introduction
Extra Mile is an initiative to help KDE applications and workspaces fix small bugs and UI issues which get in the way of the user.
KDE products are awesome, but could often be made much more pleasant to use by just ironing out a few quirks here and there.
Similar initiatives have already been run by other Free Software projects:
- Ubuntu: Papercuts
- Fedora: Fit and Finish
- Gnome: Every Detail Matters
Criteria to qualify as an "Extra Mile Bug" (EMB)
A bug is an EMB if it satisfies all these criteria:
- It must be a bug or an enhancement, not a feature request
- It affects many users
- It makes using the application harder or less pleasant
- Agreement from the maintainer
- It is easy to fix (see below)
How to determine a bug is easy to fix
A bug is said to be "easy to fix" if it can be fixed in one day by one person.
The maintainer of the application or component should be able to help decide if it can be fixed in one day. If it cannot, the bug can stay but it should not be marked as extramile any more.
Reporting extra mile bugs
Extra mile bugs are tracked on Bugzilla. We created a tracker bug to group all extra mile bugs. To mark a bug as "extra mile", mark it as blocking the tracker bug, that is: enter "extramile" in the "Blocks" field ("extramile" is the alias for the tracker bug). If you want to be notified of new extra mile bugs, subscribe yourself to this bug.
Here is a Bugzilla search listing all extra mile bugs. You can also use the "ExtraMile bugs" saved searches on Bugzilla which you can find under Preferences / Saved Searches.
We may also set up an email alias for people who want to report such issues but can not or do not want to use Bugzilla. This email alias would be a simple way to reach us so that we can file the bug for them.
Communication
This initiative is part of the KDE Quality Team, so we use the team communication channels:
- Mailing list: https://mail.kde.org/mailman/listinfo/kde-testing
- IRC channel: #kde-quality
We also plan to report progress through:
- emails on kde-devel, kde-testing
- blogs every two weeks
- articles on http://dot.kde.org
In the future we may try the following:
- Set up test days
- Define quantitative goals