#139 Proposal: Migrate Pagure issues to Taiga board on teams.fp.o
Closed: stale 3 years ago by jflory7. Opened 3 years ago by jflory7.

Summary

Manually migrate all open issues in this Pagure permanently to a new Taiga board hosted on teams.fp.o

Background

This proposal has two primary supporting reasons:

Better organization: A Taiga board offers better organizational support for the type of work the D&I Team (and many other outreach teams) do. A Taiga board could be configured with a "to do", "in progress", and "backlog" columns to better organize our work and keep track of good ideas to revisit in the future.

Better prioritization: Taiga offers us a better ability to prioritize and figure out what work is most critical or important. This part should make it easier for others to figure out where the core team is most focused and help identify good areas to get on-boarded with the team.

Details

This proposal should be put to a team vote. If approved, the implementation plan could be as follows:

  1. Create new Taiga board on teams.fp.o
  2. Figure out permission logistics for D&I Team (i.e. how to add/remove members to a Taiga project)
  3. Migrate all currently open Pagure issues to Taiga
  4. Close all open Pagure issues
  5. Update Pagure README that this repo is only used for D&I Team docs and redirect people to the Taiga board for submitting new ideas/tasks
  6. Add new docs page to introduce/explain how to use and manage the Taiga board

Outcome

  1. Easier for the core team members to prioritize our most important work
  2. Easier for new contributors to get on-boarded

+1, if we find someone to take lead on this

Also, once this is approved, I would suggest adding a date after which we need to open new issues or comment on exisitng ones only on Taiga so that contributors don't get confused mid transition.

A super +1 to it, If it gets approved, I would love to help @jflory7 with migration of Pagure Issues to teams.fp.o,

Metadata Update from @jonatoni:
- Issue untagged with: needs feedback, new change
- Issue priority set to: waiting on assignee (was: needs review)
- Issue tagged with: approved

3 years ago

We have just created it for now: https://teams.fedoraproject.org/project/fedora-diversity-and-inclusion-team/timeline but @jflory7 will work on it next week to migrate all the tickets we currently have on Pagure. @nasirhm do you have an account on teams.fedoraproject.org? so we can add you too?

@jonatoni , I do have an account on teams.fp.o as nasirhm.

@nasirhm awesome - Justin will add you, as soon as he starts to work on it :)
@jflory7 let us know how we can help

Super. I will likely work on this over the weekend or early next week.

For now, I will close out a Pagure ticket and add a link to the equivalent Taiga card in the Pagure ticket once it is moved. Keep an eye out for more soon.

Today (after quite sometime), I got some time to look at our tickets and I am not hesitant to say that how much filtering it needs :)
Thanks a lot for reviving it with Taiga board (much needed).

Suggestion - Let's make sure we don't carry stuff to Taiga which is not required or too old. We can always have new cards when we have time and bandwidth to focus on them.

@amsharma that's why one of the biggest reason about Taiga was to have "Backlog" that we can add all the ideas we don't have bandwidth to work now but we can pick in the future.

Great. Thanks @jonatoni Looking forward to get started in Taiga.

Hey folks! I propose we put this on a backlog until after Nest. I think we should avoid changing too much right before we have so much other work coming up (Nest sessions, FWD organizing, lots of docs editing, etc).

I will be more proactive on migrating our Pagure project to Taiga after Nest. I promise!

Metadata Update from @jflory7:
- Issue untagged with: approved
- Issue priority set to: waiting on external (was: waiting on assignee)
- Issue tagged with: blocked, new change

3 years ago

I broke my promise here :see_no_evil: I hope you can forgive me!

I was dragging my feet here because I am also aware of the ongoing work to explore a migration to GitLab. I am familiar with GitLab and its project management tools, so I was thinking to wait for more news on that before moving forward here.

I guess the open question to this ticket could be one of three options:

  1. Continue using Pagure, close ticket as out of scope
  2. Continue using Pagure, but plan to migrate to GitLab in 2021 when available.
  3. Stop using Pagure, migrate fully to a Taiga board in 2020.

I broke my promise here :see_no_evil: I hope you can forgive me!

No Worries Justin, You're doing alot of work :)

  1. Stop using Pagure, migrate fully to a Taiga board in 2020.

What do you think would be a better way to manage our tickets / tasks from your experience of Project Management, Taiga or GItlab ?

@nasirhm wrote…
What do you think would be a better way to manage our tickets / tasks from your experience of Project Management, Taiga or GItlab ?

I started to write a lot of text, but then I figured this pros/cons overview is more helpful:

Taiga teams.fedoraproject.org

Pros

  • Get visual! Provides better visual overview of team progress and focus
  • Prioritize and focus. Easier to identify what active/current focus is and avoid getting side-tracked in good ideas that are not timely yet.

Cons

  • Complicated. Taiga is a complicated tool to configure. I have never used a stock configuration. I always modify it heavily to get it to a place I think is actually useful.
  • UI. The user interface is very visual. People who work in CLIs often might get frustrated with its weird quirks.
  • Isolation. Not many other Fedora teams, other than the Council, use Taiga. It might be an unfamiliar tool to most of Fedora Community.

GitLab

Pros

  • Fedora Friends! Hypothetically, GitLab will become heavily used in Fedora one day, and the rest of the community will be there.
  • Non-Fedora Friends! Easier for people with GitLab accounts, but are not active Fedora contributors, to participate.
  • One stop for everything. GitLab bundles things like git repos, issues, project management tools, kanban boards, and more into one platform. We can centralize more of our work to GitLab and avoid sprawling out to lots of different places for our work.

Cons

  • Not perfect use case. GitLab is more code-focused than what our team does. Discussion is a large part of what we do, and GitLab was not designed explicitly for conversation: it was designed for code (like any git forge).
  • Unexpected quirks. Fedora + GitLab is on the horizon, but who knows when. We will likely be waiting a year or longer if we decide to wait for GitLab.

Metadata Update from @jflory7:
- Assignee reset

3 years ago

I think this is a huge amount of work and the pay-off of doing it is unclear, since we have to train everyone on a new platform. Meanwhile, we have six years of history and habits built up on this repo.

I am closing the ticket as stale. Of course, we can revisit if we want to reconsider.

Metadata Update from @jflory7:
- Issue close_status updated to: stale
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata