Developer Meetings/20121120

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
• http://www.na-mic.org/Bug/view.php?id=2608 See next week agenda
• Code associated with download.slicer.org (see below) See next week agenda
• Mantis workflow (see below) See next week agenda

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
  • Jim> The reference mechanism could be extended. The output could be put back under the associated input.
  • Steve> By default, do not copy attribute but organize/group nodes
  • Andras> Concept of pipeline / replay
  • Csaba> After RSNA, will do some prototyping using Patient Hierarchy. See SlicerRt issue #125
    • How will DICOM tags be retrieved ?
    • Steve> What about querying DICOM database based on UUID ?

• Csaba presented W/L issue
  • Easy to change the W/L
  • But also easy to modify it when not expected
  • Proposition: Move W/L away from the left button
  • Jim> Mouse cursor specific to W/L ?
  • Andras> W/L is not limited to a meaningful range. We could know from the histogram.
  • Having icon indicating the different state (W/L, Rotation, ...) would be helpful

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