Gitlab workboards

[Nate Graham]

If we use Issues in each individual project for tasks, wouldn't this 
complicate eventually migrating from Bugzilla to GitLab issues, since it 
would intermingle the user bug reporting function with developer task 
tracking and communication?

Nate



On 5/18/20 10:59 PM, Bhushan Shah wrote:
> On Tue, May 19, 2020 at 07:08:59AM +0530, Bhushan Shah wrote:
>>>    - Do we want to keep issues enabled and use them for "tasks"?
>>>    - Do we want to have separate "tasks" boards under invent.kde.org/teams ?
>>> Nico: vote for 2
>>> Marco: vote for 2
> 
> I am in highly favor of the option 1, for several reasons:
> 
> If I look at current workboard,
> 
>> https://phabricator.kde.org/project/board/35/
> 
> We have giant mix of tasks in there, we have all kind of tasks,
> 
> - Repo specific tasks: like https://phabricator.kde.org/T12248 which is
>    clearly powerdevil task.
> - Tasks which extend to two or three repositories:
>    https://phabricator.kde.org/T11670 : extends to libkscreen, kscreen and
>    kwin repos.
> - Tasks which are there for release tracking:
>    https://phabricator.kde.org/T11939
> - Tasks which have no association whatsover with any of Plasma repos but
>    different tooling being used by Plasma:
>    https://phabricator.kde.org/T6599
> - Tasks which are more towards team building and does not directly
>    affect any of repositories:
>    https://phabricator.kde.org/T12906
> 
> In my opinion all tasks can be split into this 5 categories, if I've
> missed anything please let me know.
> 
> So now if we try to translate this to option 2, we would end up with
> roughly same task boards as we have as a "projects" and giant board with
> dump of everything.
> 
> But with gitlab migration we have a choice to improve this process,
> 
> If we go with option 1 [use actual repositories for task tracking],
> 
> - Tasks which are strictly related to one single repository go into that
>    repository itself.
> - Tasks which are common to let's say two or three repositories, we can
>    either try to split them into much smaller subtasks per repositories
>    or we put them into a dummy repository called plasma/tasks
> - Tasks which have no direct association with any of Plasma repositories
>    move to specific repo outside of Plasma/ repository but keep "Plasma"
>    tag. So it can be referred/searched
> - Tasks which are there for releaes tracking are better used with the
>    milestone feature of the Gitlab rather than project boards.
> - Tasks which are specific to e.g team building and does not have a
>    specific repository associated go into plasma/tasks repository.
> 
> In practice how this would work is we would have some tags, for example,
> 
> ~VDG
> ~Plasma
> ~Wayland
> ~X11
> ~Mobile
> ~Convergence
> ~KF6
> ... more
> 
> (Those are group/instance level labels so all repository can use them),
> each repository specific tasks would move to that repository and other
> remaining tasks can move into plasma/tasks repository, which we can
> later sort into proper repository specific tasks or keep some depending
> on what makes sense.
> 
> This would IMO allow to provide better filtering as well organization of
> the tasks rather than creating "virtual" projects which have no
> association with repositories.
> 
>> # Option 2:
> [Yes I messed up numbering here, this is actually option #1]:
>> https://invent.kde.org/plasma (group)
> 
>> # Option 1:
> [Yes I messed up numbering here, this is actually option #2]
>> https://invent.kde.org/teams/plasma/ (group)
> 
> Opinions and questions welcome!
>