Get Involved/Extra Mile: Difference between revisions

From KDE Community Wiki
No edit summary
Line 1: Line 1:
== What is it ==
== Introduction ==


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.
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.

Revision as of 14:14, 13 July 2012

Introduction

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