2006/3/18, Rod Engelsman <[EMAIL PROTECTED]>: > You're on! Here's my constructive criticism for IZ: > > 1. I used to know how to get to it, but since the site has been > redesigned it takes me far too long to find it. The layout and > navigation of the site is really poor. > > Suggestion: Have a link to IZ from the Home page. Maybe under a section > entitled "Get Involved". Test the design with "people from the street". > That's what professional web site designers do.
I'm surprised that pressing "New User & General Info" is considered unintuitive. "Report a Bug" on the next screen can not be misunderstood in my opinion. > > 2. The issue-filing page is a confusing and intimidating mess. It was > designed for insiders. Altogether too many fields and drop-boxes. > > Suggestion: Design a page for "regular users" to report bugs. This page > should have maybe a half-dozen fields and boxes to consider, no more. A > QA member will have to go in and "flesh out" the bug report, but that > happens anyway with the current system. I just read http://www.openoffice.org/scdocs/ddIssues_EnterModify to see which half-dozen fields that should be kept. I asked myself these questions about each field: a. Can I provide this? b. Do I think the information will help the developers? 1. Version: The release in which you identified this issue or found the defect. Easily provided, and needed by the developers. 2 Component/Subcomponent: Identify area within the project that this issue is associated with. Fairly easy to provide, and speeds up the search for the developers 3. Platform: This corresponds to your hardware platform when you are reporting a defect. Easily provided, and needed by the developers. 4. Operating System: This is the operating system against which the issue is being reported. Note that the operating system implies the platform, but not always. For example, Linux can run on PC, Macintosh, and others. Easily provided, and needed by the developers. 5. Issue Priorities Not that easily provided. Needed by management. I think this field should be placed in an optional subgroup and defaulted to "I don't know". 6. Issue Type Not always easily provided. Good for statistics. I think this field should be placed in an optional subgroup and defaulted to "I don't know". 7. Assigned to Hard for a user to specify. Essential for developers. I think this field should be placed in an optional subgroup and defaulted to "I don't know" (or empty as today). 8. CC Not relevant for the issue itself. Obviously optional. 9. URL I think this one is hard to understand, and that this field probably can be deleted. And I think issuses should be selfcontained. What happens when this URL gets obsolete? Will the issue be misunderstood? Use attachments instead. 10. Summary: A terse, specific statement to describe this issue. Essential for the issue handling. The reporter must really try to use this field as well as possible. It is not easy, but it's worth the effort. Remember that many persons will read this. 11. Description Essential for the issue handling. The reporter must really try to use this field as well as possible. It is not easy, but it's worth the effort. Remember that many persons will read this. I agree that 6 fields should be enough (+ 5 optional (one of the current removed and one for attachments added)). I don't think there should be a separate page for advanced users, it is enough to separate the mandatory fields from the optional ones in a more clear way. Attachments: The attachment handling is not intuitive. I would feel more comfortable if I was allowed to include attachments in the same transaction as the rest of the information (both during issue issuing and when commenting on existing issues). > > 3. Either pay attention to votes or just forget about it. It's hard for > me to consider the current system as anything more than a farce. But if > votes are to be tallied and considered, then: > > Suggestion: Recognize the effort expended in reporting an issue and > credit the report with an automatic 5 votes. This would also apply to > subsequent issues that are later marked as duplicates of some other > report. When issue X is marked as a duplicate of issue Y, then the issue > Y should inherit issue X's votes. The automatic 5 votes would tend to give duplicated issues more votes. Resulting in higher priority (if used at all) for issues with a poor summary. I think the vote handling could be described better, just the link to http://www.tigris.org/editorial/safetynet.html is not that clear to me. I think the votes are good, even if they are not considered at all by the management. If I would like to fix bugs in OOo, I would probably look at the ones with most votes first (or of course those with special interest to me). /$ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
