I think many of points Andre brings up in favour of such a list are
better kept to the bugzilla itself (e.g., detecting duplicates), but
overall I agree that it's a good idea.
Davor
Katie Capps Parlante wrote:
Hi Andre,
Aha! I didn't understand that you meant a mailing list for dogfooders.
I agree with you that a community of technically skilled
users/dogfooders helping out other users/dogfooders would be a real
asset to the project. It is indeed frustrating to have a bug parked at
"works for me" when the bug still occurs for the person dogfooding --
I can see how a forum for discussing the bug would be helpful. You
bring up a good point that we have a window of a few months to think
through the mechanics about how we'll support early adopters.
Anyone else have 2c on whether now is the time to start up such a
list, in advance of Preview?
Anything else that would be helpful in establishing such a community?
We weren't really ready for that in the past, but Chandler is now
stable enough that we can start pushing on that as a goal.
Is "works for me" the right resolution for bugs the developers can't
reproduce but we know happen for end users? If not, how should we
handle these bugs? (Mail bugs in particular seem prone to this kind of
situation).
Cheers,
Katie
Andre Mueninghoff wrote:
Hi Katie,
Thanks for your interest. A little of both, I think, if I understand
your example options.
My goal is possibly the same as yours, that is, to maximize OSAF
developer productivity towards new features and functions, as compared
to following up on bug reports that have questionable reproducibility
instructions at best, or have a root cause in a misconfigured user
environment at worst. It seems to me there might be/are probably others
like me who encounter issues that occur more than once, but are unable
to reproduce these issues consistently such to be able to craft a
coherent bug report for further investigation by a developer. I think
there may be an opportunity to provide a bit of structure to the
community of "some-what technical, but non-developer" dogfooders through
perhaps a list. It could happen, for example, that more
technically-skilled dogfooders step in are assist others in
distinguishing between known issues (a.k.a. duplicate bug prevention),
user environment issues, and user expectation mismatches (expectations
speeding ahead of the release plan). Dogfooders might be able to assist
each other in verifying instructions for reproducing issues, all prior
to intial triage <grin> by the developer(s) covering the relevant
component. It seems to me that developers and dogfooders share a common
lack of interest in bug research that results in a "works for me" tag
though the dogfooder continues to experience the issue. The opportunity
for OSAF as preview approaches is to shape and manage actively the
expectations of the eventual beta users by working out in advance the
mechanics of the support of early adopters. Hope that makes sense and is
helpful.
Please let me know if you have any questions.
Thanks, Andre
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
