Re: 3.18 topics: application revival

[Andre Klapper <ak-47 gmx net>]

On the general problem: If the number of Git commit authors remains kind
of constant but the number of applications increases, then I naively
assume that the general maintenance level of applications gets lower.

Rough numbers from the release notes (actual numbers are a bit higher
because these are only taken from git master branches of modules; note
that numbers also include translators, documentors, etc):
Version: Contributors / Changes
3.2:  1270 / 38500
3.4:  1275 / 41000
3.6:  1112 / 38302
3.8:   960 / 35936
3.10:  985 / 34786
3.12: 1140 / 34236
3.14:  871 / 28859
3.16: 1043 / 33525


On Wed, 2015-04-15 at 21:33 +0100, Allan Day wrote:
> Matthias Clasen <matthias clasen gmail com> wrote:
> > 1) Patch review days - ask the community to spend a day focused just
> > on bugs and patches of one app, with the goal of working through the
> > backlog and making visible progress. In cases where maintainers have
> > gone missing, we may need to find volunteers to lead this ?

I've tried to advertise my changes to Bugzilla's "product overview" in
blog posts, including its dedicated "Patches" section. See e.g.
https://bugzilla.gnome.org/page.cgi?id=browse.html&product=gnome-shell

If new patches are not aggressively reviewed, people lose interest in
contributing. Regarding "patches in BZ", I think it is that simple.
Of course better dev tools etc / less steep learning curve for
contribution is another bikeshed territory I don't want to touch here.

> 3) If it seems that maintainership is an issue, we should approach
> existing maintainers to ask if they need help. 

Well, I assume any maintainer would say that more (wo)manpower is
welcome? Not sure if approaching is that helpful, plus what would be the
followup step?

> We could then advertise for volunteers if they are needed, or even try
> to arrange for a temporary maintainer to step in.

Does the release-team include modules too easily / early which might
have a bad bus factor (not enough developers)? 
As Fred pointed out there's https://people.gnome.org/~fpeters/health/
and the BZ product pages now also link to Git activity at the right
bottom so everybody could get a quick impression how active a project
actually is. But we don't have any plan to really see a decline and to
actively reach out. Somehow.

And we still don't have any good plan or idea how to redirect people to
areas where help is welcome when a newbie pops up in #gnome-love. IMO.

We have improved a few things though - git.gnome.org displays
programming languages of modules (if defined in the DOAP file), or the
GNOME-love bugs query on BZ's product pages is now sorted by last change
so tickets on top of the list are likely still valid entry points.
That's all stuff to make more known or document on wiki pages.

andre
-- 
Andre Klapper  |  ak-47 gmx net
http://blogs.gnome.org/aklapper/