Developer Meetings/20121204 - Revision history

Pieper: /* Conclusion */

2012-12-04T22:45:30Z

Conclusion

JChris.FillionR: /* Conclusion */

2012-12-04T22:16:32Z

Conclusion

JChris.FillionR: /* Conclusion */

2012-12-04T22:12:31Z

Conclusion

JChris.FillionR: /* Conclusion */

2012-12-04T22:11:22Z

Conclusion

JChris.FillionR: /* Conclusion */

2012-12-04T22:10:38Z

Conclusion

JChris.FillionR: /* Conclusion */

2012-12-04T21:56:44Z

Conclusion

JChris.FillionR: Created page with '== To discuss == * Slicer 4.2.2 status * Mailing questions ** [http://slicer-devel.65872.n3.nabble.com/Nifty-Reg-and-Slicer4-tt4026920.html NiftyReg and Slicer4] * Code associate…'

2012-12-03T18:06:15Z

Created page with '== To discuss == * Slicer 4.2.2 status * Mailing questions ** [http://slicer-devel.65872.n3.nabble.com/Nifty-Reg-and-Slicer4-tt4026920.html NiftyReg and Slicer4] * Code associate…'

New page

== To discuss ==
* Slicer 4.2.2 status
* Mailing questions
** [http://slicer-devel.65872.n3.nabble.com/Nifty-Reg-and-Slicer4-tt4026920.html NiftyReg and Slicer4]
* Code associated with download.slicer.org (see below)
* Mantis workflow (see below)

== Conclusion ==

== Additional material ==
=== Code associated with download.slicer.org ===
<pre>
// ------------------
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
</pre>

=== Mantis workflow discussion ===

<pre>
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
</pre>

<pre>
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
</pre>

<pre>
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
</pre>

@@ Line 17: / Line 17: @@
 * Alex> Will look at the problem with saving/restoring camera position: http://www.na-mic.org/Bug/view.php?id=2758
 * Jc> Retrieve the details regarding NiftyReg and Slicer4.
 == Additional material ==

@@ Line 15: / Line 15: @@
 * Alex reported issue related to QVTKWidget + cache update. See http://www.na-mic.org/Bug/view.php?id=2815
 ** The idea would be to reproduce the issue using VTK6 and discuss with Clint Simpson (maintainer of QVTKWidget)
-* Alex> Problem with saving/restoring camera position: http://www.na-mic.org/Bug/view.php?id=2758
+* Alex> Will look at the problem with saving/restoring camera position: http://www.na-mic.org/Bug/view.php?id=2758
 == Additional material ==

@@ Line 15: / Line 15: @@
 * Alex reported issue related to QVTKWidget + cache update. See http://www.na-mic.org/Bug/view.php?id=2815
 ** The idea would be to reproduce the issue using VTK6 and discuss with Clint Simpson (maintainer of QVTKWidget)
 == Additional material ==

@@ Line 13: / Line 13: @@
 * Nicole will submit an issue illustrating with more details the problem associated with MRB.
 ** In order to have a stable release preventing the user from getting in "unwanted" state: What about disabling SceneView in the release ? Or MRB? Gather feedback from the community doing a survermonkey ?
-* There is an issue related to QVTKWidget + cache update. See http://www.na-mic.org/Bug/view.php?id=2815
+* Alex reported issue related to QVTKWidget + cache update. See http://www.na-mic.org/Bug/view.php?id=2815
 == Additional material ==

@@ Line 13: / Line 13: @@
 * Nicole will submit an issue illustrating with more details the problem associated with MRB.
 ** In order to have a stable release preventing the user from getting in "unwanted" state: What about disabling SceneView in the release ? Or MRB? Gather feedback from the community doing a survermonkey ?
 == Additional material ==

← Older revision		Revision as of 21:56, 4 December 2012
Line 7:		Line 7:

	== Conclusion ==		== Conclusion ==
		+
		+
		+	* Nicole and Steve will be looking at issue 1690
		+	* Change number of extensions displayed on the catalog
		+	* Nicole will submit an issue illustrating with more details the problem associated with MRB.
		+	** In order to have a stable release preventing the user from getting in "unwanted" state: What about disabling SceneView in the release ? Or MRB? Gather feedback from the community doing a survermonkey ?

	== Additional material ==		== Additional material ==