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 <[email protected]> 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 | [email protected] http://blogs.gnome.org/aklapper/ _______________________________________________ [email protected] https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
