New Common Issues process trial — private experiment

Continuing the discussion from Proposal: Migrate "Common Bugs" from the wiki to Ask Fedora:

Okay, so! I spent some time hacking this Thanksgiving, and the result is: we have some categories set up:

… and a planned workflow, which is: create proposals for the list in Proposed Common Bugs, and then we’ll work on them there and promote them when they’re ready. When a release is EOL, we’ll move the bugs to the archive.

To facilitate this, I’ve written some documents in the About section for each of those categories, and I’ve created a @common-issues-triage team. And, this Thanksgiving break, I created @issuebot, or “Common Issues Bot”. It’s not quite ready for prime time, but I think ready for an introduction. This is a script which will help with the maintained of these categories, as requested by Adam on the QA team.

This bot:

  • scans bugzilla for bugs with the CommonBugs keyword, and if those bugs don’t already have a whiteboard entry pointing to the existing pages in the wiki or to Ask, it automatically files a new template bug in Proposed Common Issues with a link back
  • scans topics in the Common Issues and Proposed Common Issues categories for bug links, and then makes comments on the topics here if there are new package updates noted in those bugs.

In the future, it will also:

  • note bug state changes (like, “CLOSED:FIXED”!)
  • clean up bugs in the Proposed category which we decide we don’t want to keep
  • move bugs to the Archived category when the time is right.

Right now, it’s run manually by me. But I intend to get it hooked up into production running on a schedule.

Also in the future, it could:

  • learn about upstream trackers and follow them too
  • be triggered by the message bus, not simply on a schedule
  • notice related posts and link them automatically
  • other things!

So, I think this covers, in the list above: 1, 2, 3, not 4, 5, 6, 7 (not yet, but in theory), 8 (with more work to be done), 9, and is a start on 10.

The other thing we need is people committed to making this work. So, hopefully, reader, that’s you! it shouldn’t be a big deal, but basically we need a triage team to watch incoming posts in the proposed category, follow the related bugs, write helpful text, decide if we want to promote or decline proposals, and also moderate replies to the proposed topics.

If you’re interested please apply to join the Common Issues Triage Team Group. Right now it’s only me only a few of us, so more are welcome. You may have noticed that the categories aren’t visible yet to people outside that group — that’s still by design so as to not confuse people who don’t know where this is coming from.

Next Steps

  1. Get interested people signed up.
  2. Anyone signed up can play with creating issues in Proposed Common Bugs. It’s basically a workspace, and we can delete and clean up later.
  3. I will change @issuebot to work on F35 bugs even if they have the wiki link in the whiteboard, and it will create a bunch of new proposed topics for F35.
  4. We’ll work through the process on those topics — there’s text to copy that the QA team has already put together at Common F35 bugs - Fedora Project Wiki
  5. I’m going to finish a few more things I have in my brain in issuebot (see the current script in pagure!, but then I’d like
    a. to get it running in production somewhere
    b. someone else to volunteer to help maintain and enhance
  6. Learn from the process and adjust the docs, the bot, and of course, the process itself — my imagination for how it works might not match practical concerns!
  7. Once we’ve got the existing F35 issues converted, open up the categories to the public
  8. possibly keep both processes going in parallel for the rest of the F35 release? hopefully we won’t have a lot more coming in
  9. decide before the F36 branch if we want to keep doing it.

What should be done regarding rejected common-issues-proposed?

Here’s my current suggestion:

If we discuss and decide that it’s not something we’re going to promote, we’ll mark the topic in Proposed Common Issues as closed. If it stays closed for a week, the bot will mark the post as unlisted. We’ll be able to get to it for history if need be, but it won’t stay as clutter.

I’m open to other ideas. For example, we could instead trigger on votes, or even use the polling feature.


That sound reasonable.

Now we have the first entry:

I can’t see that link. It says it is private for me.

Yeah, there’s only one because I discovered that I forgot to request permission for the bot account to write to the bugzilla whiteboard, so it crashed. :slight_smile:

1 Like

Yes, that’s true. I’ll bold that in the top post. :classic_smiley:

I think this makes sense as a trial run. I can’t wait to see the places where reality diverges from the plan, but I don’t know that we can make it any better until we actually put it into action.

One thing I foresee is the issue of untriaged issues. I’m not sure of the best way to solve this, but if all of the triage team is distracted for a while, issues will just sit forever. It might be good to have a nudge process. (Or maybe regular meetings? I’ve had it in my head to try to revive the BugZappers team in some form, but that is a big, scary task that I haven’t been brave enough to try yet)

That said, let’s not:

I think that’s going to be a recipe for endless complexity. Bugzilla has fields for external trackers. We could pull that and put it in the bottom as a list of “related issues” or something but not try to query for state, etc.

Yes. @issuebot can do it! Several possible thoughts:

  • can send messages to the group
  • can just randomly bump topics that have been sitting there
  • can post a warning that the issue is getting stale, possibly to the related bugzilla entry, potentially causing whoever nominated the bug to speak up
    • and then if it still is stale, decide no one cares and remove the issue
  • automatically put a post in The Lounge, Site Feedback, or Announcements begging for more people to join the team
    • escalate to twitter if that doesn’t work?

I came this close to naming the common-issues-triage group bugzappers. It’s not too late!

1 Like

I’ve made the categories public for all to see! Let’s continue this thread over at: We are testing a "New Common Issues" category and process