Bugzilla – Full Text Bug Listing
| Summary: | Attributes section in new bugzilla task should be initially expanded | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Willian Mitsuda <wmitsuda> | ||||
| Component: | Mylyn | Assignee: | Robert Elves <robert.elves> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | ||||||
| Version: | unspecified | ||||||
| Target Milestone: | 0.8 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows Vista | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Willian Mitsuda
+1 for that. I also think that attrs section should be also expanded on existing task editor, so it would be possible to see product, component and target milestone. Summary is just not enough to get the bug context. It also seems like personal planning section would look better at the top... What if we auto expand it for new bugs and for bugs that are being read the first time, and keep it collapsed for others? I.e. assuming that for new or unread bugs you need to see it, but when repeatedly visiting bugs you often don't so it's worth collapsing or imposting the click. Oh, and if anything changes in attributes we auto-expand as well. Same with attachments. This makes for a consistent policy across attributes and comments: if there is something unread, it's section gets expanded. The attribute section now represent a quite weird mix of the important and unimportant things, as well as actions available trough links... It also seem better to have resolution and target in the summary section at the top. Can we apply mylar to the bug editor? Sorry, I couldn't resist to make this joke :) Humm... thinking better, apply mylar to the bug editor does not sounds so crazy, besides the joke :) We are here discussing about what is important or not in the editor, but isn't Mylar all about freeing the user from having to decide what is relevant or not, based on the user habits? For the "new bug" case, would be possible to monitor the user habits whenever it uses the "new bug" editor (not a specific case) and use all this information to decide what is relevant or not? For the "existing bug" case, it can maintain context information per-resource. Nope, not a joke, I think that these are very good suggestions Willian :) Yes, we actually had this support way back in the 0.2 prototype, so that things like the Bugzilla comments would have a DOI and could be filtered in the Outline. Now that this is becoming a real issue in the editor it seems high time to step back and consider this... Fixed. New bug editor attributes expanded by default. Left planning where it is since it seems to me that when creating a new report the workflow is: define the work item, schedule work item, submit work item. Will address auto revealing of attributes etc under bug 142039. Created attachment 52046 [details]
mylar/context/zip
|