I’m looking at Issue #380: Purchasing PinePhone Pro units for Fedora KDE and Mobility SIG members - tickets - Pagure.io, and noticing that it has a lot of discussion (much of which is my fault) about “What’s an Objective” and “What’s an Edition?” — both good general Council Discussion topics. It’s often the case that a lot of useful / interesting bits like that get into our ticket threads, which has some distinct disadvantages:
Distracts from the flow of the actual issue to be addressed
There’s not really a good way for people to properly respond / participate without further driving off from the topic of the ticket
These useful / interesting bits are easy to miss because they’re off in a ticket repo somewhere, not … well, here.
And it’s possibly even worse when there’s a big conversation that stays on topic, because now there’s an important conversation that perhaps should have wider community input.
And, it’s kind of hard to find and refer back to these conversations later.
I see the same thing happening on FESCo tickets and on other teams as well. Anyone have any ideas for making this better?
One of the ways of ensuring visibility of these tickets is, as much strange as it may sound, to not have tickets at all but have threads on Discussion fp.o. under the council tag. Titles like [COUNCIL] Discussion needed on yada-yada can help distinguish threads too.
Alternatively, we can move the ticket repo over to GitLab and make use of the Kanban board there to better triage the tickets. Stacks can include to be discussed, needs more context, discussion complete, outdated/stale etc.
I don’t think that’s the right approach. Having a ticket queue is useful for tracking the status of things that need to have status tracked. And moving to GitLab doesn’t really change anything. Pagure has a Kanban board, too. This is less about the technical implementation and more about the practice, IMO.
I think the best approach is to be more aggressive about using “this is off-topic, please go discuss it at Discussion instead” in tickets.
As much as I want to Put Everything On Discourse, I don’t think it’s the right tool for the job. [1]
However, one thing I could do, as I am writing Discourse Bots Aplenty, is make a thing that listens to the message bus for new council tickets, and posts a new discussion thread here linking to the ticket, and then a post to the ticket saying “Please use the ticket for formal votes and status tracking, and discuss → over here”.
Having the right tool would make it easier to achieve the best practice. Imagine having a tight integration between pagure and discussions where the discussion for a ticket is happening with the features of discourse. There you can easily move discussions to a new thread (AFAIK). Likewise it would be nice to have this in pagure to move a discussion to a new thread in discourse or to a new ticket. If the tooling helps with this (making this a single click event that creates links to the new discussion etc) would be awesome.
@till Do you think you could bring this to Mindshare committee as a suggestion to try out? My current script isn’t super-smart — it just sets up the topic and links back to it — but I think is a good proof of concept and we can enhance it if it seems worthwhile after trying for a bit. I’ve got it set up for just the Council now but theoretically I wrote it to be able to handle mapping any tracker on Pagure to any tag (or tags!) here.
A lot of stuff like this where interesting work happens somewhere but no one outside the direct / small group who participated knows about it can generally be offset via routinely-practiced communications.
So for example, if a ticket / bug gets hot and there’s good discussion around it… or a thread on this thing goes wild… or there’s a twitter or Matrix chat discussion of intrigue and import… or there’s a particularly productive team IRC or video meeting with lots of great stuff…
That’s the kind of stuff that could be summed up in a regular routine communication for the team involved. So people who “weren’t there” can know what happened and those who are more async, or volunteers who stepped back for a few weeks bc of life, can follow along or catch up easily.
The routine is hard and the writing a time investment but I remember the days when everyone wrote blogs of this type at a regular cadence without too much overhead organization and it felt like the thread that wove the communities involved together. The Balkanization of communication channels I guess is unavoidable at this point but it’s really eroded the ability for someone not working full time on Fedora to be able to follow along especially as the project grows more complex technology wise.
Anyway the next step on top of being mentioned in a routine (and by routine I mean with a regular cadence - weekly / monthly / whatever) communication, is to escalate it to something more permanent in the form of a doc since routine communications with a time-based schedule scroll out of view…
