Get Involved/Extra Mile: Difference between revisions

From KDE Community Wiki
(Created page with "== What is it == Extra Mile is an initiative to help KDE applications and workspaces fix small bugs and UI issues which gets in the way of the user. KDE products are awesome, b...")
 
No edit summary
Line 28: Line 28:
== Reporting extra mile bugs ==
== Reporting extra mile bugs ==


Extra mile bugs are tracked on Bugzilla. We created [http://bugs.kde.org/show_bug.cgi?id=extramile|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).
Extra mile bugs are tracked on Bugzilla. We created [http://bugs.kde.org/show_bug.cgi?id=extramile|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.


We may also setup 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.
We may also setup 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.
Line 35: Line 35:


This initiative is part of the KDE Quality Team, so we use the team communication channels:
This initiative is part of the KDE Quality Team, so we use the team communication channels:
* Mailing list: We use the mailing list of the KDE Quality team (kde-testing@) to discuss extra miles. You can subscribe to it from here
* Mailing list: https://mail.kde.org/mailman/listinfo/kde-testinge
* IRC channel: #kde-quality
* IRC channel: #kde-quality
* Mail on kde-devel, kde-testing and blog every two weeks
 
* Testdays: to be decided later, if we feel there is a need for them
We also plan to report progress by sending reports on kde-devel, kde-testing and blogging every two weeks.
* Quantitative goals: not for now, we will see later
 
In the future we may try the following:
* Set up test days
* Define quantitative goals

Revision as of 14:13, 13 July 2012

What is it

Extra Mile is an initiative to help KDE applications and workspaces fix small bugs and UI issues which gets 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:

Criterias to qualify as an "Extra Mile Bug" (EMB)

A bug is an EMB if it satisfies all this criterias:

  • 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
  • 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 deciding if a can be fixed in one day. If it cannot the bug can stay but it should not be marked as extramile anymore.

Reporting extra mile bugs

Extra mile bugs are tracked on Bugzilla. We created 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.

We may also setup 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:

We also plan to report progress by sending reports on kde-devel, kde-testing and blogging every two weeks.

In the future we may try the following:

  • Set up test days
  • Define quantitative goals