Hi Nate, On Mon, Apr 27, 2020 at 07:45:23AM -0600, Nate Graham wrote: > Trying to categorize everything into a single group cannot succeed because > many projects could logically belong to multiple groups (e.g > plasma-framework is a framework that's a part of Plasma; Discover is an app > that's a part of Plasma; kdenetwork-filesharing and kio-extras are libraries > that are distributed via the apps release service). I foresee endless > pointless arguments about the best group for something to live in.
I've agreed in previous threads that sometime our grouping is not perfect, but this is something we can improve instead of throwing idea of grouping out altogether. > Let's step back: do we have to put every repo inside a group in the first > place? Is it solely so you can look at a nice list of all open merge > requests for PIM/Frameworks/etc? If so, perhaps this workflow could be > approximated with tags instead or group assignments instead No goal is not just that you get nice list of all open merge requests or issues. Main goal is we want to offer user or potential contributors a list of closely related projects instead of list of all 1100+ projects we have. That would mean, If user wants to see all frameworks, or graphics applications, or multimedia applications, they can. The workflow, with labels you mention is trying to achieve a totally different goal then what we are trying to solve here. Labels/Tags are for sorting issues, and/or merge requests. They can't be reliable solution for the sorting of the multiple repositories. On technical side, Gitlab does not offer labels for projects, but setting called topic. You can see that in screenshot[1] linked. Besides, from home page there's no way to filter something for e.g "Graphics". nore project listing shows the tags alongside of the project names, also making use of this tags means that if user clicks this tags, what they are offered is *all* the repositories including forks of the repositories, which means when you search for graphics [2], you get many duplicative results and this is really not something discoverable. > We create many very granular groups for the purposes of organizing teams and > and performing code review (e.g. Plasma, KWin, Frameworks, PIM, Krita, > Dolphin, Okular, VDG, etc.) and then every new merge request could receive a > tag or assignee corresponding to its relevant code review groups (e.g. merge > requests for kio and kio-extras could get get tagged with both "Frameworks", > and "Dolphin"; plasma-frameworks MRs could get tagged with both "Plasma" and > "Frameworks", and so on). As explained above, while grouping repositories is trying to solve the merge requests/issue organization, it is not sole purpose of the suggested grouping, discoverability and reachability is the main issue we are trying to solve here. [1] https://i.imgur.com/h1L1A5H.png [2] https://i.imgur.com/ajOszEL.png -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
signature.asc
Description: PGP signature
