KDE Frameworks: Moving toward 5.0 final and Governance

[Alexander Neundorf]

On Monday 06 January 2014, Kevin Ottens wrote:
> Hello all,
> 
> Now that TP1 is almost out of the door, it is time to move toward the final
> release and put in place the governance of KDE Frameworks. It is a very
> large and multi-faceted product, so we will need people with longer term
> commitment if we want it to shine on release day.
> 
> ## What's left for a final?
> 
> Short answer:
> http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation
> (Tasks for Final Release section)
> 
> To get there, we'll move into a monthly release schedule:
>  * Alpha 1, February 1st;
>  * Alpha 2, March 1st;
>  * Beta 1, April 1st;
>  * Beta 2, May 1st;
>  * Final, June 1st;
> 
> Between beta 2 and final we'll insert release candidates following a
> shorter weekly cycle to nail down the remaining minor issues.
> 
> We don't expect the source code to drastically change between now and
> final. At least, short term, we shouldn't see code flying from one
> framework to another one. As you can see most of the tasks revolve around
> the tooling next to the code (CI, buildsystem, apidox, etc.)... Still
> there's one big elephant missing there as it's not really something
> actionable: code quality.
> 
> I urge everyone, and in particular people volunteering to maintain a
> framework, to do a pass of review of our code base and APIs to modernize
> them when appropriate. It is a very big task, and in no way can be
> coordinated in the way we've been working so far. Maintainers will be a
> crucial part of a successful code quality review, which leads me to the
> governance...
> 
> ## Frameworks Governance?
> 
> I used to say that the maintenance model of kdelibs was "David Faure by
> default". It's great to have someone like David around, but at the same
> time it's delusional and dangerous to think that he'll always be able to
> save the day. This model has to stop now. And hopefully having smaller
> packages will help people to feel responsible for their modules.
> 
> The current list of modules is there:
> http://community.kde.org/Frameworks/List
> 
> As you can see there's quite some holes in the table, and quite a few
> entries marked unmaintained. KDE Frameworks as a set of technologies will
> only be taken seriously if we get something more complete there. I urge
> everyone with an interest in KDE Frameworks to step up, look at that list
> and volunteer to maintain a framework. If you volunteer, know that the
> following will be expected from you:
>  1) Complete in the table the information regarding your framework;
>  2) Do an API review and modernization pass in your framework (possibly
> with the help of others);
>  3) Stick around for a long period to act as maintainer (see below for
> details);
>  4) The day you want to move away from your duties, do so responsibly,
> don't just disappear, make sure you pass the torch to someone else
> (probably the most important point in the list!).
> 
> ### Governance at the framework level
> 
> At the framework level, the maintainer will be responsible for the quality
> of the code produced. In particular he'll have to make sure the different
> policies in place are respected inside his module:
> http://community.kde.org/Frameworks/Policies
> 
> In practice that means that the day to day activities (and minimum required
> from a maintainer) will be to:
>  * Review others' code;
>  * Make sure that his module is always in a releasable state (in particular
> the CI is always green);
>  * Decide on the direction his module is going in case of conflicts.
> 
> Note that we're not expecting maintainers to have ideas on features or on a
> direction to give to the module (of course they can, it's just not
> required). That means it is fine to be more of the reactive type of
> maintainer if you want to, letting contributors propose directions and
> trying to move the lines, you just have to pick one in case of conflicting
> goals.
> 
> ### Governance at the KDE Frameworks level
> 
> Because of the structure of KDE Frameworks (which is already more than 50
> modules and that number will likely increase again for 5.1), we also need
> to have a body that looks at the overall coherency of the whole. My goal
> here is not to create a huge bureaucracy, so we'll start as small as
> possible and grow if the need arises.
> 
> To bootstrap this body, we'll reuse something as close to the status quo as
> possible. In our case that means that the KDE Frameworks Release Team will
> start with David Faure and myself.
> 
> The responsibilities of that team will be the following:
>  * Beating the drum on the product rhythms (mostly the release schedule,
> but also interim meetings);
>  * Defining the content of the overall product;
>  * Defining the rules of work.
> All of that in the usual KDE fashion, that is by collecting information
> from the trenches (that is the maintainers and contributors).

IMO something like proposing the maintainers and approving them, similar to 
Qt, would be good, i.e. at least some kind of "voting" by who we will be 
"governed".

Alex