GNOME module list suggestions about fornalder HOT 5 OPEN

if I may also chime into the bikeshed.

I find the question about important underlying libraries very interesting. With my gstreamer hat on I could tell you that intersection between a gst and a gnome developer is a sizable group of people, but there are also a lot of activity that comes from other sources. The way that activity would be counted, if at all, would be very interesting, do we identify the people with strong associations to gnome and group the rest separately? Should those projects get a plumbing category of their own? Do we ignore them for now to avoid the hassle?

I think those are similar to other sizable projects, like mesa, systemd, pulse, webkit, NetworkManager, wayland family, xorg too, or probably most of the projects hosted on freedesktop.org infrastructure. We will likely find former or still active gnome people involved with the majority of them and being heavily invested into them.

There's also another category of fd.o projects that exist currently where they are developed mostly by gnome people, but given their nature that will likely change in the future are they are meant as generic infrastructure. What comes to mind is things like bolt, upower, accountservice, pkg-config, libfprint, plymouth, and probably more of them.

I don't really know how to conclude this comment other than, dumping theses shower thoughts here. But I really appreciate the effort that has been put into these analytics/metric and its very valuable! Thank you!

from fornalder.

Thanks for the detailed feedback! I was indeed trying to cast a wide net. Regarding missing modules, gnome-online-accounts seems to be there, and clutter history was merged into mutter's if I'm not mistaken, but it looks like I missed the others on your list. At a guess, this will have an effect on the commit counts, but probably not much in the active authors count, as there's a lot of developer overlap. I feel extra bad about missing shotwell, geary, polari and gnome-builder!

I like your suggestion for a split -- if I'm understanding correctly, we'd end up with three categories: "F/OSS desktop plumbing", "GNOME platform/infrastructure/docs" and "GNOME/GTK flagship applications". Then we could get a better fix on how the platform proper is doing, and expand the plumbing and applications lists a bit. I guess minimum criteria for the latter could be "more than $N LOC, relies on GTK widgets". Or maybe instead of/in addition to LOC we could select by number of downloads on Flathub, or distro numbers (Debian popcon?).

As a footnote, I guess the questions I'd like to answer are along the lines of:

• How many people are highly experienced in developing and applying GNOME technologies?
• Is that group likely to grow or shrink?
• What is the churn rate like, and is experience being transferred well?
• Are there any signs of stagnation or burnout in general?
• How have past group decisions affected the project and the group itself?

I was interested in the C# projects because they were developed by people with vast GNOME experience and intended as desktop centerpieces, but the technology occupied an awkward space and was eventually rejected. There have been other projects that met with dead ends too, and I thought it made sense to include them because I see it as part of the group effort. Similar things happen within modules when branches fail to be merged or code is rewritten/retired.

from fornalder.

If I may chip into the bikeshed...

Maybe aggregating all the jhbuild modulesets over time would be interesting. I saw that gnome-panel is missing, which was a big part of the action in GNOME2.

I like the idea of splitting by categories! I suppose you'll find much more drive-by contribution in applications than in the core platform, but who knows.

from fornalder.

I like your suggestion for a split -- if I'm understanding correctly, we'd end up with three categories: "F/OSS desktop plumbing", "GNOME platform/infrastructure/docs" and "GNOME/GTK flagship applications".

I was imagining two categories: "GNOME" and "core dependencies". The primary motivation for that is to remove any skew from projects that are (semi)independent from GNOME and whose "health" might not reflect the health of the GNOME project itself. For example, I don't think contributions to GStreamer, which is used far more widely than GNOME and is fairly independent, can be simply interpreted as commits to the GNOME project.

This isn't to say that these core dependencies aren't important to GNOME, or that contributions to them aren't relevant to us, which is why I'd analyse them separately.

To me, creating categories for platform/infrastructure/docs versus GNOME/GTK is potentially interesting, but has a different goal. My suggestion is intended to ensure validity of the analysis.

(Side note: if we were to examine levels of contribution across modules - super interesting! - I would personally be more interested in identifying categories empirically rather than a priori. Which modules are most active over time? Which ones have low/high contributor turnover? etc, etc.)

(Edit: also on per module contribution levels - it would be really interesting to analyse which modules are primarily supported by which companies. You might well see that some are primarily developed by one company, whereas others have shared support.)

from fornalder.

Fair enough. GStreamer felt GNOME-y to me because of its strong GLib tradition and usefulness to the desktop, and the developers sometimes show up at GUADEC too.

I'm toying with the idea of a "plumbing" category that could serve the function of "core dependencies" for more DEs than just GNOME. May be a pipe dream though. It depends on what other projects would consider core and not (e.g. KDE vs. Qt).

from fornalder.