On Mon, Nov 08, 2021 at 08:54:04AM -0800, Adam Williamson wrote: > > 1. The new process needs to make sure that Bugzilla entries with CommonBugs > > keyword are triaged in a timely manner. > > 2. When proposed Common Issues* are accepted, the whiteboard field in > > Bugzilla is updated. > > 3. All accepted entries need to follow a consistent format, ideally using > > some form of templating. > > 4. We need templates to deal with special cases like those which require > > installer images, or where a workaround is needed even when an update is > > available. > > 5. Entries need to be updated with instructions when a candidate fix is > > available. > > 6. And further updated when a fix is released. > > 7. We figure out something to do about archiving at EOL time. (Although this > > doesn't necessarily need to be in place until... F38. Could be part of a > > general plan to archive older topics on Ask Fedora.) > > 8. We have new documentation covering the new procedures. > > 9. We have tooling in place and/or people commited to cover all of the > > above. > > 10. More automation would be lovely, but at least we don't want it _less_ > > automated than the current state. > > > > Does that cover it? What did I miss. > > That's more or less it, except that it doesn't cover how update- > commonbugs helps a *lot* with points 5 and 6. Doing that manually is a > drag. What I'm thinking it would do for 5 and 6 is: * For each topic in the Common Issues (including Proposed) category that isn't marked as solved, * check periodically for bodhi updates (I think by looking for the Fedora Update System messages in bugzilla?), * and if those updates were posted after the last such reply, * post a reply to the topic with (filled-in) boilerplate appropriate to the candidate or expected fix state (and possibly other metadata from the topic itself). (This bot would have permissions to reply in the Common Issues category, as would QA team members.) I _think_ we would rely on humans to mark the issues as definitely "solved". Okay, hmmm, before I go further with this, let me check something: Package updates aside, how important is it for this process to be bugzilla-driven at the start? Or, in bugzilla at all? Is it: - "migration requirement for with least possible change and annoyance", or - "bugzilla adds an important tracking element", or - "since these issues are _bugs_, bugzilla is inherent to the whole concept" - something else? ? If we made the process for "nominate a bug" be "post in the Proposed Common Issues category" rather than "add CommonBugs to the bugzilla keyword field", what would we lose? Advantages would be: * More laziness for me (not needing to do steps 1 or 2 of the list above) (probably would still want automation to help with 5 and 6 though). This is non-trivial laziness, as 2 at least requires _writing_ to bugzilla, while 5 and 6 could just read. * As I understand the semantics now, "CommonBugs" keyword means "maybe common bug?" and "CommonBugs + properly-formatted URL in the whiteboard field" means "actually common bug". Which is... kind of arcane. It seems like "is issue in Proposed category or the accepted one" is a lot more obvious. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
