#112 Switch from Pagure to Taiga
Closed: Fixed 4 years ago by chrismurphy. Opened 4 years ago by aday.

This issue has been split out of #106 and there's some background discussion in that issue.

The main reason I'm proposing this change is that I think that a Kanban board would be useful in helping the WG focus on a smaller number of priority and in-progress issues. I personally find Kanbans to be really effective.

Some secondary motivations:

  • A number of other "managerial" teams are switching to Taiga and I think there's a general move happening (including the change wrangler, and having the Workstation WG use the same platform would be helpful.
  • Taiga has the concept of sub-tasks, which can be useful

Some miscellaneous points raised in #106:

  • The WG's issue tracking needs aren't complex, so a simple solution is therefore OK
  • Kanbans are only necessary once you have a lot of tickets
  • Taiga isn't all that super in general

@tpopela has been managing the Silverblue Taiga project and I asked him about the experience. What he said:

  • The default fields are rather basic
  • You can set custom fields, but can't search by them
  • You have to add people to the project through a clumsy process
  • You have to change the project settings if you want people with FAS accounts to be able to comment

Simple suggests we may grow out of it sooner than later, but then also it should have a low barrier to entry - other than initial setup. I'm in favor of giving it a shot until something clearly better becomes available.

We approved creating a taiga instance (+5,1,-2). Here it is:

https://teams.fedoraproject.org/project/workstation-wg/timeline

The remaining question is whether to enable the Pagure sync extension that Neal has recommended. I think this would be a good way to start using Taiga.

...

The remaining question is whether to enable the Pagure sync extension that Neal has recommended. I think this would be a good way to start using Taiga.

I'd be fine to give that a go.

The extension could also help address Matthias's concerns about having two separate tools (which I share). With the extension enabled, we would never need to look at Taiga except to view the kanban, because the discussion in both tools should be synced. And the kanban would certainly not be redundant with Pagure.

Metadata Update from @catanzaro:
- Issue tagged with: meeting

4 years ago

Is someone able to set up the Pagure sync extension, so we can have a play around with it?

I think @pingou would be able to help here...

Is someone able to set up the Pagure sync extension, so we can have a play around with it?

might be safer to setup a test taiga instance, enable the sync against it, see the result and then consider whether we want to enable it "for real"

@langdon yes please; something we can mess up and just delete (?) and then create a new instance when ready to go live with it. I spent about 5 minutes trying to figure out how to create something, anything, and didn't succeed before I was distracted by a squirrel.

I was unable to accept my email invitation to join our new Taiga project. The invitation mail always takes me to a login page, even if I am already logged into Taiga. After logging in, it does not redirect me to a page for accepting the invitation.

Slightly off-topic, but i think we're currently lacking a mechanism to track action items after each meeting. Maybe we should file issues for these in Pagure, with an "action" label?

@langdon yes please; something we can mess up and just delete (?) and then create a new instance when ready to go live with it. I spent about 5 minutes trying to figure out how to create something, anything, and didn't succeed before I was distracted by a squirrel.

Done: https://teams.fedoraproject.org/project/workstation-wg-1/timeline

NOTE: there is TEST in the project name and description but the differences may be otherwise very subtle. Worst case, we can recreate the real one if it gets messed up.

I was unable to accept my email invitation to join our new Taiga project. The invitation mail always takes me to a login page, even if I am already logged into Taiga. After logging in, it does not redirect me to a page for accepting the invitation.

You might have luck with logging in to teams.fp.o, make sure it attaches the right email address and try again. I can also reinvite you once you have an account.

I just asked about the Pagure sync extension. According to @pingou it is a proof of concept and is at an early alpha stage. It doesn't sound like it's for us right now.

Since the group seemed keen to continuing having a presence on pagure.io, I think this means we either need to manually duplicate issues in Taiga, or give up on the idea.

You might have luck with logging in to teams.fp.o, make sure it attaches the right email address and try again. I can also reinvite you once you have an account.

Oh, I'm already logged in. That's no problem. The problem is that the invitation page just ignores that and treats me as if I'm not logged in.

Apparently the invitation actually worked, it just looked as if it didn't work. I see my account is a Product Owner in the Workstation group. OK then.

Since the group seemed keen to continuing having a presence on pagure.io, I think this means we either need to manually duplicate issues in Taiga, or give up on the idea.

I guess we can leave it up to whoever winds up serving as Chair and takes responsibility for managing the issues, to decide whether the Kanban is important enough to merit duplicating issues in two different places. My preference would be one tool, Pagure only.

I guess we can leave it up to whoever winds up serving as Chair and takes responsibility for managing the issues,

Yeah, it makes sense to wait and see who ends up doing what.

That said, I do think that someone ought to track our outstanding action items and that will need some updates to our tooling, whether it's new tags in Pagure or a Taiga instance.

My preference would be one tool, Pagure only.

Yeah, I get that reasoning. The one thing that's pulling me towards Taiga right now is that we're likely to have some duplication anyway, if we want to split out action items somehow. Having Taiga just for WG actions is liable to be about the same amount of work as logging actions in Pagure and having a separate place for them might be beneficial.

My preference would be one tool, Pagure only.

Yeah, I get that reasoning. The one thing that's pulling me towards Taiga right now is that we're likely to have some duplication anyway, if we want to split out action items somehow. Having Taiga just for WG actions is liable to be about the same amount of work as logging actions in Pagure and having a separate place for them might be beneficial.

I don't see why we would "duplicate issues" :

  • Pagure is for us or external parties to file and keep track of open problems. We may or may not be working on them, they may or may not be broken down in to actionable steps, etc.
  • taiga is for when work is happening, generally but not always, tasks/stories/epics will have a link to some issue in pagure.

An example might be "refresh the PRD." In theory something we should do every year (ish). However, it isn't really an issue, it has many steps and work assigned to different people. I would think this is the kind of thing on taiga but not on pagure.

A reverse example might be a non-wg person asks "could you please explain the diff between silverblue and workstation?" which they file in pagure. Definitely not "actionable," instead, we might build some cards in taiga to update the docs on this subject and there would be a link to the instigating issue. Then the "close" of the pagure issue would be "See new docs".

I was trying to figure out how we could track action items in Pagure, and ended up coming to a similar conclusion to @langdon . We likely want to split out action items from the "issue" they relate to, so the "duplication" would happen anyway.

Also, using Pagure tags to track the progress of actions would be quite painful.

I started adding some items from our recent discussions into the test Taiga instance, so we can see what it could look like.

During the meeting today, we decided to let the newly appointed Chair & Vice-Chair recommend usage and usage model. We should see a resolution to this issue in a couple weeks. We might even be able to close the issue now.

Metadata Update from @catanzaro:
- Issue untagged with: meeting

4 years ago

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

4 years ago

Login to comment on this ticket.

Metadata