On Sun, Nov 20, 2016, 1:12 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
On Sun, 20 Nov 2016 04:49:54 +0000
Liam <liam.bulkley(a)gmail.com> wrote:
...snip...
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.
Well, we already have bugzilla that both reporters and developers can
communicate on (and also anyone else who is interested).
If there is interest in this I can draw up a much more detailed proposal
but, as I said in the initial post, I have ZERO idea of how to integrate
the two changes to the bugzilla side of things. I'm told that the codebase
is a cyclopean nightmare-scape full of squamous things with too many limbs
and a space that is rather less reliable than the one of common
acquaintance. That said, changes may not even be required, as it's possible
bugzilla already supports reporter names not associated with a bugzilla
account and a way to make easy updates to the reporter's ip (assuming
bugzilla even supports raw ip addresses).
This would still use bugzilla (... sorry, I thought I had mentioned that
elsewhere). This is targeting the problem—as referenced by Josh—with
getting the majority of users to actually both report problems and
providing a SEAMLESS way for the developer to get back in touch with the
reporter. So, absolutely this is still using bugzilla, but it's changing
the way this particular type of user would interact with it.
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.
What do you mean by 'system notification' ? Some direct pop up dialog?
That could be pretty anoying.
That's one of the reasons why it would be opt-in. This is looking to fix a
problem that I can attest to having experienced (and can also relay that
other contributors to Fedora have as well): making the entire process
seamless.
- I encounter a bug and the abrt gui notifies me about it, so I attempt to
be a good user and file a report.
- Assuming all goes well (hey! I've got an account! but I don't remember my
password so into the browser I go...) the report gets filed.
- Sometime later I get an email...which I don't see because I get a lot of
email, or I don't get a lot of email and only check it occasionally, or I'm
just not diligent at checking my email because it's not a place where I do
the majority of my communications, etc; and I don't heavily interact with
bugzilla, so it's not something my mail client knows to prioritize,
assuming it didn't toss it as spam.
- For one of those or some other reason, I don't respond to it. In the
best case, the bug gets a +1 from other users who then pickup the slack I
left. It's more likely that it gets closed automatically after 90 days (or
whatever) of no activity when the bug is at the state of needinfo.
To briefly address your concern, this isn't really intended for high volume
bug reporters, but people who are "just" users, but who can still help us.
And if we can provide a simple, positive experience of a process they may
be utterly unaware of, we might provide another avenue that can generate
new contributors. Those who are already contributors could also benefit
from the simplicity of an integrated process.
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.
One thing we are planning on doing for them soon is to allow them to
login to bugzilla via their
fedoraproject.org account. Of course then
they have to make one of those if they don't have it, but they won't
need to also make a bugzilla account. Might help some folks out.
Yeah, that's really another permutation of this whole issue.
Before, I was making the case regarding one particular type of user (the
casual, unengaged one) for which the integrated experience provides as low
a barrier as I can reasonably imagine, but there's also the other set of
users who do, if they feel up to it, create accounts, file bugs and brave
Bugzilla whenever they get an email, but don't always get back to the
developer who needinfo.
I would much prefer to just use the one app that I used to submit the
report to handle all of these issues. Issues which are really TIED to that
particular desktop from which the report came, and not my email account,
such can be accessed from any of several devices. My side of the
interaction should really only occur if I'm at the computer which was the
origin of the report.