How to promote less mature Frameworks?

[Mark Gaiser]

On Fri, Aug 15, 2014 at 12:12 AM, Àlex Fiestas <afiestas at kde.org> wrote:
> Hi there
>
> At the Randa sprint we have discussed a little bit what to do with those
> frameworks that are still not mature (for example they can't commit on ABI/API
> stability) but they are ready for feedback from third party developers.
>
> Even though there was not consensus in the discussion this is an idea that
> came out during the discussion:
>
> -We introduce a Maturity level that we can use to manage expectations about
> the Framework (for example whether API/ABI will be kept)
> -We release Frameworks that are not ready together with the rest, but we have
> to make damn sure we manage expectations.
>
> With this we can get early feedback for new frameworks, and since we have a
> rapid release cycle we can improve them fast.
>
> What do you think?

It depends on how you define maturity.

For instance, if a maturity is simply a value set in each project'
metainfo.yaml and set by those that maintain it then the maturity
level quite frankly doesn't tell you anything.

But if you decide maturity dynamically based on git activity, api/abi
stability, number of people contributing and where the project itself
is used in other projects (just some conditions that i can think of
now, there is probably more). With this a project maturity actually
has a meaning. When going for this approach it would also be nice to
show a list of projects using "Framework X". Also, i do not consider a
project being healthy when it has only one developer [1] even if the
project is used by dozens of other projects and has much activity. For
us - kde devs - we probably don't care much if a framework is being
developed/maintained by one person, but for external potential
framework users that will be a concern. Specially companies.

[1] http://en.wikipedia.org/wiki/Bus_factor