Solid/HowWeWork: Difference between revisions
| Line 8: | Line 8: | ||
As many other KDE applications, we're using the [https://bugs.kde.org/ kde bugtrack] to manage bug tracking. All projects are within the product Solid as components, using the most friendly name possible, for example instead of BlueDevil we're using "Bluetooth". | As many other KDE applications, we're using the [https://bugs.kde.org/ kde bugtrack] to manage bug tracking. All projects are within the product Solid as components, using the most friendly name possible, for example instead of BlueDevil we're using "Bluetooth". | ||
Each project has a general category, on which a bug triager is assigned who should move the bugs to a more low level, for example moving a bug from libsolid to libsolid-udev. | Each project has a general category, on which a bug triager is assigned who should move the bugs to a more low level component, for example moving a bug from libsolid to libsolid-udev. | ||
== Patch Review == | == Patch Review == | ||
Revision as of 10:52, 26 November 2010
What is a Solid Project
A Solid project is any kind of software or initiative related to hardware or system integration which is ruled by the Solid Team. All the projects operate in the same way, being this the only requisite to be a Solid project.
Communication
We use primarily two ways of communication, irc and mailist. Each project can have they own, but everybody should be in kde-hardware-devel and #Solid in irc.freenode.org
Bugs
As many other KDE applications, we're using the kde bugtrack to manage bug tracking. All projects are within the product Solid as components, using the most friendly name possible, for example instead of BlueDevil we're using "Bluetooth".
Each project has a general category, on which a bug triager is assigned who should move the bugs to a more low level component, for example moving a bug from libsolid to libsolid-udev.