<snip>

> >user then has to manually collect what's asked for, and then manually
> >attach it to the bug report. I see a significant minority of bug
> reports where a developer asks for more information and there's never
> >a response again from the user.

>That's related what I'm talking about. The reporting of the bug is
>not the problem. It's the continued follow through from both user and
>developer that is. A developer is not going to magically fix a PM bug
>on a machine they don't have when they can't get feedback and
>information from a user.

It is a melancholy object to those who browse through our great zilla of bugs or render their regards unto the pamphlets of their peers, when they then see the sites, the feeds, and gazetteer on the corner, crowded with congeries of the converted, followed by three, four, or six choruses, all in rage, and importuning every soul for their allegiance. These hierophants, instead of being able to work for their honest livelihood, are forced to employ all their time in weeding their beds while having to beg assistance for their plightless cause: who as they mature either turn management for want of work, or leave their dear native country to fight for the Lord of Redmond, or sell themselves to the Cupertinoes.

I shall now therefore humbly propose my own thoughts, which I hope will not be liable to the least objection.


Just for bug reports submitted via abrt (or whatever might replace it), might we not offer an opt-in service whereby the reporter can communicate with the developer uniquely via a per bug token. The point of all this is to provide a seamless way for casual users to report bugs and remain in contact.

The biggest change this would induce, and the reason for the opt-in, is that when someone triages the report, they have a direct channel to the reporter via a blessed system notification (assuming the reporter doesn't have a static IP, this would require a phone home to update the ticket with the current IP, though that's not the only way to do this, but these are implementation details). It's the system notification that is the big difference, and that's the thing which is most likely to get a casual user's attention.

Yes, this is a big change, though the development side isn't that complicated, at least from the user to the Fedora side of matters (though, from there, I admit I'm not positive how the bugzilla side would work). It may not even be worth it if the resources don't exist to fix the reported issues.

What it does, imho, is something similar—possibly better—to Windows/macos by providing well integrated service support. It might even be desirable to, eventually, provide a way for a developer to ssh in if the problem is particularly unusual (but for that i think legal would need to be pretty involved) and it doesn't require an account to be created. As it has been mentioned before when this topic has come up, creating an account is rather more onerous than some think, since it's not just the steps involved, or that the person will have yet another account to keep in mind, but that last extra bit of the positive potential barrier they must overcome if they want to report their problem. It's this group—casual users unlikely to have a bugzilla account—who I think is likely the largest group, and I feel we've not done as much as we could to embrace them.