Solid/HowWeWork: Difference between revisions

From KDE Community Wiki
 
(One intermediate revision by the same user not shown)
Line 28: Line 28:


Its main goals are to:
Its main goals are to:
* identify new goals for the coming release which might have appeared;
* 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;
* 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.
* start discussing the autumn sprint planning.


=== Autumn Sprint ===
=== Autumn Sprint ===
Line 40: Line 40:


==== Objectives ====
==== Objectives ====
Forge has two main objectives related to our community:
Forge has three main objectives related to our community:


* Hacking away to nail down the remaining hot topics for the N+1 release
* Team building;
* Identify further areas to tackle for the coming year
* 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.