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:
Some miscellaneous points raised in #106:
@tpopela has been managing the Silverblue Taiga project and I asked him about the experience. What he said:
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.
...
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
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...
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?
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.
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.
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.
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" :
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
Metadata Update from @chrismurphy: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.