While we have a page that lists all Core and Circle apps with apps.gnome.org, we don’t have something similar for the rest of our projects like libraries, language bindings, shell, etc.
The Current Plan
Due to repeated requests to also cover this part of GNOME a bit better, and my constant drive to aggregate data, I have created a simple listing of everything that’s not an app.
The plan is to provide it under developer.gnome.org/components in the future.
Additional Ideas Welcome
The current page is very simple. If anyone has ideas for how to make it more useful or look nicer. The project can be found within Websites Team.
Updating Metadata
The data is aggregated from the projects .doap-files. The icon is the project avatar (organization avatar on GitHub).
Project icons should be generated with the Emblem app as PNG using the “Square” option. They can be either set using the GitLab options or by adding a “logo.png” to the project’s root.
We should have avatar icons (e.g. 'D' for dconf, 'L' for libpanel, libpeas with different bgcolors) as fallback to app icons to have uniform visual layout.
Some app icons are getting clipped, as they were designed for square layouts (tecla, orca etc) not circular ones.
This was a nice way to highlight areas of GNOME that really need more contributors, things that are usually invisible … e.g. when Nautilus is under-maintained lots people notice because we look at it daily, but when Christoph Reiter maintains the Python bindings single-handedly for years on end it’s not immediately obvious.
Out of curiosity, do you have an idea how we could show info like this in the new components page?
I would like to avoid creating new data sources. The concept behind all my data aggregation is that metadata about projects should be maintained within a project. What could work is creating a mapping from which automated merge requests are created.
Not really. But mainly I’m not sure if we can find a good automated metric. If a project has frequent commits, the maintainer could still be overworked etc.
We had “looking for maintainer/help” sections in Wiki. Not sure how effective they were. We could add a mechanism somewhere that would allow a maintainer to label a project as “needs help” and automatically tag them or whatever. But in the end, I think announcements on blogs or TWIG have been far more effective than a list that nobody checks.
For apps, we use app overview in Circle Committee and Release Team. That allows us to catch apps that need attention in some areas. Would certainly be possible to set this up for components as well if we have relevant metrics.
Playing with the currently available data is relatively easy. They are all available as JSON API.
Instead of tweaking DOAP files, what about importing the gitlab topics flags?
(not necessarily for grouping, but at least to let users filter on them?)