Information regarding upcoming Gitlab Migration

[Bhushan Shah]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200428/337d0494/attachment.sig>