This issue was brought to FESCo a few days ago:
https://pagure.io/fesco/issue/3568
We briefly discussed this during today’s meeting (meeting log starting at 18:46:51) and determined that this would be better suited to a broader discussion before deciding on action items (if any).
Personal opinion, not speaking for FESCo:
I understand that the amount of bugs that are filed against some of these components is ridiculous, and that the auto-responder that was set up for most GNOME packages was supposed to help with this.
But I don’ think the auto-responder has actually helped at all. Bugs are still being filed - likely at least in part because there’s no indication that you’re filing a bug against a component where you’ll just get a “go away” auto-response. Additionally, once the form is filled and submitted, people likely feel like their “work” is already done, and then they’re asked to go do all that again somewhere else.
The auto-response text also explicitly says that downstream / packaging bugs and / or bugs for release tracking purposes should remain open, but also
Bug reports for this component on Red Hat Bugzilla are not actively monitored
which sounds like a “have your cake and eat it too” situation. If valid downstream / packaging bugs should remain open, then bugs for these components also must be monitored, otherwise keeping these kinds of bugs open is just pointless.
IMO even having the auto-responder auto-close issues and asking people to reopen bugs for downstream / packaging-only issues would be better than the status quo. That way at least the signal / noise ratio of OPEN bugs for these packages / components should be way better, and actively monitoring them would be a lot easier.
One fundamental problem is that many reporters don’t know how to differentiate between packaging problems and upstream issues. It seems like it is also wrong to send them all upstream and make them triage Fedora issues.
In the ideal world, perhaps someone could be recruited to help triage issues so the package maintainers don’t need to personally handle all of them?
FESCo policy is that package maintainers need to deal with reported bugs in a timely manner. Setting up an auto-response to say “we’re ignoring this bug” conflicts with that, so I think either the policy or the auto-response needs to be changed so things are in alignment. If this results in changing of policy, then the non-responsive maintainer policy should probably be updated as well to state that ignoring bugs isn’t grounds for being considered non-responsive.
In my packages, if I get a Fedora bug report for something I know is an upstream issue, I’ll link it in the Fedora bug and close it with the UPSTREAM resolution. If I can’t find an existing upstream issue, I’ll encourage the reporter to file one or file it myself. I consider that a normal part of bug triage, and think most packagers (not just in Fedora but in many distros) feel the same way. Logically if you ignore that triage work for a long period of time, the number of unresolved bugs may feel insurmountable, which seems to be the case here. The maintainer responsibilities policy specifically suggests asking for help on the devel and test lists, teaching others how to triage bugs, and adding co-maintainers. These seem like great first steps to try before a policy change is considered. In the meantime, the bug auto-responses are giving a very negative impression about the quality of Fedora.
This is also how I operate too. That said, I do have a large pile of bugs too, and I try to dedicate some time to evaluating them. I also actively re-evaluate bugs every time I ship an update for a package (it’s very easy when Bodhi gives you a list in the web form). I imagine most packagers attempt to operate somewhat like this.
A great number of upstreams would be very angry if users were sent to them to report bugs for packages as a default. And in general, the job of a Fedora package maintainer is to identify, curate, and work with upstream. That can also mean forwarding bugs on your own, or requesting the submitter to do so.
As a point of comparison, Fedora KDE has not requested a similar setup despite also having a very heavy bug reporting load with many components delivered to users. We do look over the bug reports periodically and I do use the information to identify trends. It has actually been pretty handy when I need to have conversations with upstream about larger issues.
We are, however, quite bad at tagging bug reports to be closed when we ship KDE stack updates. I have not yet figured out how we can improve this aspect, but it is something that we should eventually tackle. 
I personally do not think it’s a good idea for any Fedora contributor to be ignoring our central bug tracker system, nor is it a good idea to convey that bug reports are ignored by default.
To me, actions like this make it feel like Fedora is not providing value to the user or the upstream. Because if maintainers aren’t doing that funnel work or leveraging shared infrastructure to help improve the quality of the components they maintain, I don’t know what they are doing.
With Forgejo, we should be able to replace the auto-responder with an issue report template, so you see our message before filing your bug report, rather than after. I’ve found this to be a highly effective strategy in the Epiphany issue tracker on GitLab. Before I could set issue report templates, I used to routinely close probably half of the issue reports by redirecting users to WebKit Bugzilla. Nowadays, I only occasionally have to close an issue report as a WebKit issue, because most users see the issue report template and immediately redirect themselves.
GNOME won’t be angry so long as we are reporting bugs for recent software versions and not ancient software versions. This is a mainly a problem for longer-supported distros like Debian, Ubuntu, or RHEL. Fedora’s short release cycle inherently fixes this for us.
In practice, most bugs are upstream bugs, not packaging issues. Yes, there are many exceptions, but in general, asking users to start upstream is going to be much more successful than starting downstream and getting nothing. Users who report GNOME bugs to upstream have a decent chance of the bug being fixed. Users who report GNOME bugs to Fedora have little to no chance of that. I strongly suspect this holds for most of our packages, not just GNOME. Now, we do have many exceptions where the downstream packager diligently responds to issue reports! But surely this is an exception, not the rule. So I suggest we focus on fixing our bug tracker and bug report tooling to report bugs in the correct place.
But yes, when somebody actually does want to report a packaging issue, that just gets lost currently. You have to manually contact a developer to have any chance. I agree that this is a problem.
I really don’t think it’s realistic to expect packagers to read the downstream bug reports. Which is why reopening the issues won’t work: nobody is watching. All other downstream issue trackers have the same problem; you’ll find that Debian’s issue tracker is probably just as bad as ours, and Ubuntu’s is surely much worse.
P.S. I myself actually do read my downstream bug reports, as do a few other GNOME developers. But this only works for me because I own comparatively very few packages.
I think most GNOME packages are owned by inactive developers who don’t contribute to Fedora anymore.
Bugzilla supports templates, we used them before we started using the guided form thing. That’s not really an excuse since we could use it for this purpose too.
Debian’s maybe, but that’s because the ergonomics of that tracker is so bad that even GNU (who created it) doesn’t use it anymore. My experience with Launchpad for Ubuntu is that they are actually fairly attentive, even if they are slow to act on anything (I spent nearly a decade working at a company who ran Ubuntu in production and had to deal with it fairly significantly, so I’ve got decent experience with interacting with Ubuntu).
I’m not so sure that’s the case. That said, software bugs matter to us too, because as an integration project we have to figure out what to do with these things. That’s why we track software bugs in our Fedora release development process.
And the thing is, telling people to go to GNOME GitLab (or in the KDE case, KDE Bugzilla) is a bad path in the first place because there is no 1:1 mapping to how we maintain and track a component and how upstream does. You’re also telling users to deal with people who may or may not have any real influence on how soon a fix reaches them. It’s perfectly reasonable after some triage work to push it upstream, and that’s what we as maintainers are expected to do.
Telling everyone to go to the GNOME GitLab by default doesn’t help us because then we at the Fedora level know nothing and we can’t do prioritized backports/cherry-picks, etc.
GNOME’s lifecycles, priorities, etc. are not the same as ours, and defaulting to telling them to go there makes them think we have no agency of our own to support our users.
While it’s kind of off-topic, I am not a fan of moving from Bugzilla to a forge based tracker for exactly this reason. As someone with a lot of packages, Bugzilla’s advanced structured data model and querying capabilities are the only reason I’m able to keep track of anything at all.
So, as others, I try and answer bugs, but as others I am often too busy
to keep up on them as much as I would like.
If someone reports something thats beyond what I can do as a downstream
(it’s a real bug in the thing, it’s an enhancement request, it’s more
complex than I can figure out), I usually ask the reporter to file
upstream and if they do not wish to do so, I will on their behaf.
Of course when I do that I become a middle man between upstream and the
reporter, or don’t explain things as they might like, so I try and
direct people to file themselves.
On a higher level, I really liked @mattdm’s vision from a while back:
We direct users to discussion first. Here they can explain their issue
and if it turns out to be a actual bug, people here can guide them where
best to report it. That might be in a distribution place if it’s pretty
clear to be a distribution thing, or upstream if it’s pretty clear it’s
an upstream thing.
I also think its good to have expectations for people filing bugs, and I
think thats what the gnome messages were trying to do. You at least know
why the report isn’t going anywhere. Of course it’s much better if we
can provide that informaiton up front…
I don’t really have a dog in this fight, but I can only relate a bit of personal experience from over here in openSUSE-land.
It’s become a bad practice, for folks to use our Factory Mailing List, as some sort of a “workaround” to filing bugs on our bugzilla, usually in the guise of “I’m not sure if it’s a bug” or “I don’t think this is bugworthy”, or as a method of getting “priority access” (my term) to the maintainers, because being loud gets your problem attention.
Which is honestly what I would suspect would happen, if users were encouraged to open Discussion threads.
I personally, as a maintainer (and in my limited exposure as a developer), would rather just see the folks that “aren’t sure if it’s a bug or not” just file the bug, it’s less work for me to get a report that isn’t a bug, and close it with some explanation, than it would be to have to keep an eye on both Bugzilla and Discourse (in fedora’s case) because people are talking about issues with something I maintain, but never actually filing the bugs.
It’s not a 1:1 comparison, granted, but just some food for thought.
Whether or not you think it’s realistic, it is the current policy. If you think the policy needs to be changed then please propose those changes instead of simply ignoring the policy.
I suspect that policy has never been followed at any point in Fedora’s history. I would support changing the policy, but I don’t plan to work on this myself.
Multiple people in this thread have said that they do (or at least try to) follow this policy, so that’s clearly not true.