<div dir="ltr">Having used it for some years at Boeing, I find that gitlab has a competent task management capability in the form of Issues.  While at Boeing, and apparently at JP Morgan Chase, there was also an alternative (WIP Work-In-Progress tool in Boeing-speak) in the form of Jira (integrated with gitlab), I found gitlab sufficient - particularly for software maintenance - because it fits nicely with an adapted KANBAN development process.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 25, 2023 at 2:31 PM Nate Graham <<a href="mailto:nate@kde.org">nate@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/23/23 03:48, Ben Cooksley wrote:>     Also, in Phabricator, Tasks <br>
have no real "home"; they just have project<br>
>     tags, and they can have multiple such tags to be able to belong to<br>
>     multiple projects. For example "VDG" and also "Plasma". Such a Task<br>
>     shows up in both projects' workboards. But in GitLab, Issues need to<br>
>     live in one place and only one place. So for such Phab tasks, we would<br>
>     need a way to determine the single new home of the Task in GitLab, and<br>
>     perhaps tag them with global-scope labels or something?<br>
> <br>
> <br>
> Yes, we would need to do a deconflicting process there.<br>
> Any thoughts on the best approach to that?<br>
<br>
At least in the case where a Task is tagged with VDG and also something <br>
else, it probably makes sense to have it live on GitLab in the <br>
"something else" project/group/etc. Back in the Phab days, we used to <br>
tag everything VDG-relevant with the VDG tag, but on Gitlab it probably <br>
makes more sense to just CC the "@teams/vdg" group instead.<br>
<br>
Nate<br>
</blockquote></div>