Solid/HowWeWork: Difference between revisions
| (7 intermediate revisions by 2 users not shown) | |||
| 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 == | ||
We're using (as many other KDE projects) reviewboard as web interface to submit patches, it allow to us to keep tracking of patches. | |||
Currently there are two review boards, [http://git.reviewboard.kde.org git] and [http://reviewboard.kde.org svn], you should use one or the other depending on where the project is hosted (SVN or Git). Since KDE is moving towards Git, is to be expected that in the future will be only one reviewboard. | |||
== Yearly Meeting and Sprints == | |||
We try to meet formally and IRL at least three times per year. | |||
=== Winter/Spring Meeting === | |||
It turns out that most of the core-metalworkers are also involved in other sub-communities of KDE. So in winter or spring we apply a "cuckoo" approach and try to have a short informal meeting during one of the developer sprints organized early in the year. It happened for instance during the Tokamak 4 in 2010. | |||
The goal of this short informal meeting is to identify the broad goals we want to tackle for the coming year after the latest release (which generally happened shortly before the meeting). | |||
=== Summer Akademy Meeting === | |||
In the summer, for Akademy, a fair share of metalworkers are attending. We then meeting during a longer Solid BoF. | |||
Its main goals are to: | |||
* identify new goals for the coming release which might have appeared; | |||
* track progress regarding all the goals stated, and see which one should be top priority for the coming release; | |||
* start discussing the autumn sprint planning. | |||
=== Autumn Sprint === | |||
==== What is a sprint? ==== | |||
Sprint is a small event where we all sit together (in a physic place) and work on Solid related things. | |||
The Solid sprint has a proper name "Forge", and we try to organize 1 a few months after Akademy. | |||
==== Objectives ==== | |||
Forge has three main objectives related to our community: | |||
* Team building; | |||
* Hacking away to nail down the remaining hot topics for the N+1 release; | |||
* Identify further areas to tackle for the coming year. | |||
Latest revision as of 13:31, 27 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.
Patch Review
We're using (as many other KDE projects) reviewboard as web interface to submit patches, it allow to us to keep tracking of patches.
Currently there are two review boards, git and svn, you should use one or the other depending on where the project is hosted (SVN or Git). Since KDE is moving towards Git, is to be expected that in the future will be only one reviewboard.
Yearly Meeting and Sprints
We try to meet formally and IRL at least three times per year.
Winter/Spring Meeting
It turns out that most of the core-metalworkers are also involved in other sub-communities of KDE. So in winter or spring we apply a "cuckoo" approach and try to have a short informal meeting during one of the developer sprints organized early in the year. It happened for instance during the Tokamak 4 in 2010.
The goal of this short informal meeting is to identify the broad goals we want to tackle for the coming year after the latest release (which generally happened shortly before the meeting).
Summer Akademy Meeting
In the summer, for Akademy, a fair share of metalworkers are attending. We then meeting during a longer Solid BoF.
Its main goals are to:
- identify new goals for the coming release which might have appeared;
- track progress regarding all the goals stated, and see which one should be top priority for the coming release;
- start discussing the autumn sprint planning.
Autumn Sprint
What is a sprint?
Sprint is a small event where we all sit together (in a physic place) and work on Solid related things.
The Solid sprint has a proper name "Forge", and we try to organize 1 a few months after Akademy.
Objectives
Forge has three main objectives related to our community:
- Team building;
- Hacking away to nail down the remaining hot topics for the N+1 release;
- Identify further areas to tackle for the coming year.