<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.