Ok after a small chat with the Bhushan I learned that the plan is to use gitlab-triage instead of project labels. This should be way more powerful :D
Sorry for the trouble Carl ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Le mercredi, avril 29, 2020 2:37 PM, Carl Schwan <c...@carlschwan.eu> a écrit : > Hi Sysadmins, > > since we are speaking about workboard for groups, what is the plan for groups > that don't work on a single project but on all of the KDE projects (e.g. VDG, > documentation, localization, websites)? > > I experimented a bit with project tags > (https://invent.kde.org/groups/kde/-/labels). This would allow subscribing to > only a certain sort of issue and code review. The problem with project tags > is that it only works if all the projects share the same root (e.g kde) but > we can still have a hierarchy kde/graphics, kde/plasma, kde/frameworks. > > This is already a problem since at the moment there is no way to ping VDG > and/or Promo in a merge request concerning the websites. I guess it is fine > for KDE Web because we are a small group and I can ask a review in > Matrix/Telegram. But I'm not sure it will work well for VDG and Promo who are > already bigger groups. > > So maybe we should go with the option to go with namespaces having all the > same root? > > Sorry for complaining so late. I still think the GitLab migration is a good > thing and there are more advantages than disadvantages in the migration. So > if you think project tags are not the way to go and there is a better way, I > will trust you. > > Thank you sysadmins for all the works you are doing making KDE infrastructure > better. :D > > Cheers, > Carl > > Le mercredi, avril 29, 2020 1:16 PM, Adriaan de Groot gr...@kde.org a écrit : > > > On 2020 prilula d. 29id 06:46:55 CEST Bhushan Shah wrote: > > > > We have gotten a request for namespacing from projects on multiple > > > occassion, in cgit our workaround has always been that we prefix the > > > repo name with namespace- (i.e wikitolearn-courses-backend). > > > While this works out with our current workflow, it is not really > > > optimal. I've also mentioned various new contributor focused > > > requirements which lead us to this proposal for structuring in previous > > > emails. > > > Your mention of namespaces reminds me that there wasalso a discussion in > > this thread about workboards and reviews. > > > GitLab can have one workboard per group. So depending on how the > > categories / namespaces work out, we have choices in the overall number of > > workboards: > > > - one big one (flat) > > - one per (sub)group / namespace > > > We should look at this as well. Arguments I've seen in this thread > > > > > - one big one is unmanageably large > > - (sub)communities have asked for smaller (split) workboards > > - split workboards make it harder to work over group boundaries > > - one big one allows moving reviews and tasks to where they belong > > > (The last point is "because there are no group boundaries"). > > > > > From the sound of it (without re-reading this entire thread today) it's > > a > > distinction between generalists and specialists and a good workflow > > depends on > > what it is you're trying to coordinate (drat, another "it depends" > > issue). > > > > > [ade] > >
publickey - carl@carlschwan.eu - 0x7F564CB5.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
