...like defining /mediawiki/skins/ as a project so with one click you can filter on any related activity in all skins.
Would have to happen via project.json files to create. Cannot do this ourselves until Bestiary tool is in place.
Note that projects are not disjunct I was told: two projects could contain the same repository.
T179240 is a potential usecase here (one project = one engineering team).
Discussed this idea at FOSDEM 2018 with Bitergia.
For the records, we could already do this, see Wikimedia as the current only top-level item in https://gitlab.com/Bitergia/c/Wikimedia/sources/blob/master/projects.json
However I'm not convinced if my idea is really the best use case, as it is organization specific. So while this might be one solution, I am not convinced that it is also the best solution for the underlying 'problem' of making filtering relevenat views per engineering teams a bit less cumbersome.
For the records, currently the default workboards https://wikimedia.biterg.io/app/kibana#/dashboard/Overall-Community-Structure and https://wikimedia.biterg.io/app/kibana#/dashboard/Community-Structure-by-Project show the same things because we have 1 project. Coming here from T245854.
(Rephrased task summary to describe a goal instead of a potential implementation.)
Reworked upstream Hatstall will likely see a "Teams" feature in 2023 for individual identities, however this initially won't be reflected in the frontend so not much use for others.
However, @mafesan mentioned last weekend the possibility to set aliases: Edit repository entries in https://gitlab.com/Bitergia/c/Wikimedia/sources/blob/master/projects.json by adding a parameter --label=["teamname1","teamname2"] which would allow querying for that label in the frontend.
However, this would both increase manual maintenance costs and is not feasible as long as https://www.mediawiki.org/wiki/Code_stewardship_reviews is rather disfunctional.