Difference between revisions of "Developer Meetings/20121120"
From Slicer Wiki
m (→Conclusion) |
m (→Conclusion) |
||
Line 10: | Line 10: | ||
* Resolve the light box issue for 4.2.2 release | * Resolve the light box issue for 4.2.2 release | ||
** Nicole> Calculation of the renderer id is failing is failing when slice spacing different from 1 | ** Nicole> Calculation of the renderer id is failing is failing when slice spacing different from 1 | ||
− | |||
− | |||
** Jim and Nicole sorted out confusion regarding spacing in the lightbox | ** Jim and Nicole sorted out confusion regarding spacing in the lightbox | ||
+ | * Andras presented the issue regarding the extra information associated to Volume | ||
== Additional material == | == Additional material == |
Revision as of 21:31, 20 November 2012
Home < Developer Meetings < 20121120Contents
To discuss
- Light box index calculation with volume spacing taken into account (comment 07293 http://www.na-mic.org/Bug/view.php?id=1690)
- Plan for Markup module (will replace Annotations module): Backward compatibility, release date, ...
- Potential solutions for defining roles and/or attributes for volumes that are preserved when the volume is processed. See http://slicer-devel.65872.n3.nabble.com/Volume-node-subclass-tt4026807.html
- W/L mouse button. See http://slicer-devel.65872.n3.nabble.com/Left-mouse-button-changes-window-level-Is-it-good-tt4026815.html
Conclusion
- The plan is to have Markup module available for January
- The idea is to implement the same feature as Slicer3
- Resolve the light box issue for 4.2.2 release
- Nicole> Calculation of the renderer id is failing is failing when slice spacing different from 1
- Jim and Nicole sorted out confusion regarding spacing in the lightbox
- Andras presented the issue regarding the extra information associated to Volume
Additional material
Code associated with download.slicer.org
// ------------------ JC, please check the selections for the pull down menus on the left side of the page. Please note that they are not affecting the URL. slicer.kitware.com is the source, download.slicer.org/stats is the official face. I asked Mike to change the appearance of the circles. I did not like the bio hazard signs. Ron // -------------- Hi Ron, Given the fact the page you mentioned [1] has been developed by Mike and also considering that the source code is not publicly available, we can't update it, test it or provide patches. May be we should think about unifying effort and avoid redundant work ? Thanks Jc [1] http://download.slicer.org/stats // -------------- JC, A good topic for the hangout. Unfortunately, I am not going to be joining next few weeks. Ron
Mantis workflow discussion
Hi Folks, To bring light in our mantis workflow and clarify the terms "Assigned", "Acknowledged", "Confirmed", "Resolved", "Closed", I invite you to look at the following page: See IssueWorkflow As a developer, an issue is assigned to you, then you can eventually ask for feedback. If the work to be done is understood, you then acknowledge the issue. It is only when you start to work on an issue that you confirm it. When the work is completed, you resolve it. The reporter will then close it. Note also that the IssueWorkflow page as been referenced from the pages: Report a problem, Create a feature request , ContributePatch, Developers/StartHere. Let me know if you have any question, Thanks
Hi JC, I think that's too complicated, we want to encourage users and developers to use Mantis to report and fix bugs and this adds even more steps to the process. The Mantis interface has so many options that it's already hard to use and I'd prefer a move to simplification rather than complication. I'd propose taking the confirmed/acknowledge steps out and replacing them with posting notes: As a developer, an issue is *assigned* to you. The developer optionally asks for *feedback*, the bug reporter responds to the feedback request, and either the reporter or developer resets the issue to *assigned*. The developer posts notes to the bug page as it's being worked on. Once the work is completed, the developer *resolves* it. The reporter will then *close* it or *reopen* it with a note. How do other developers feel? Can we discuss this during the hangout today? Nicole
Hello fellow Slicer developers, I agree with Nicole on having a simple and succinct workflow since Mantis is the only collaboration/update/status tool for Slicer developers. I propose having names that are intuitive: "New"/"Backlog" for when a new bug is reported. No need for "assigned" as it gets assigned immediately. "Active Development" for when the developer starts working on it. "QA/Review/Testing" - the developer updates the bug to this status when he is done working on it and would like fellow developers to review/test it. This can be optional based on the priority and triviality of the issue. "Resolved/Customer-QA" - When developers are satisfied "Closed/Re-open" for the reporter/customer to evaluate the solution. Sankhesh