[Insight-developers] Procedure for contributing new classes

[Luis Ibanez]

Hi Dan,

I share your concerns, and also agree with Gaetan's comments.

It is true that the process of moving contributions from the IJ to
Code/Review has become the bottleneck of the process of
extending the toolkit.

Our expectations of getting three reviews for every paper simply
didn't materialize in practice.

The IJ is very successful in getting contributions, and it is very
successful in disseminating the contributions to the ITK community.

We know, however, that even when users find useful papers and
code in the Journal, they are too happy using the code to remember
to spend some minutes in writing a review.   :-)

As you pointed out, we should find a mechanism for speeding up
the process of moving these IJ contributions into ITK.

One important rule, as Gaetan pointed out, is that the author of the
paper shoulnd't in general, be the ones moving the code. The reason
is simply that in that case, there is no "code review". The authors will
always find their method names, class names, and designs to be
perfectly logical (even if they are not so to other developers).  Having
an independent developer go through the code and review it during the
process of getting it to work in the Code/Review directory, is probably
the strongest review that the code will have during its lifetime in the
toolkit.

Just moving code straight into the Code/Review is not a good option,
in my opinion, because:

    *    The code doesn't get to be announced to the community
    *    The code doesn't get to be audited during the transition


Instead,
My suggestion will be to invoke the shear power of the community.

We have accepted that writing reviews is boring and unappealing.
...That's fine...

What I would suggest then is to have a program similar to the
"Adopt-a-Bug", in which we engage the community of users and
developers to join the fun of actually dealing with the code.

In this "Adopt-a-Paper" program, a user will receive the same privileges
that any other developer, (CVS write access, developer level in the Bug
tracker) and will go straight to move the code contribution into the
Code/Review directory.

We will be happy to support these volunteers and to guide them through
the process of adding code to the toolkit. This should prove to be more
interesting for them, than writing reviews.

In order to harvest the power of Open Source, we should target to have
something around 20% of the users to have CVS write access and to
be trained on how to contribute to the toolkit by following the test-driven
software development process (100% code coverage, zero warnings,
zero errors, all platforms supported... etc).


Expanding the involvement of new generations of ITK users is vital
to maintaining a healthy community.


The essential question is:

  How do we motivate the person who just found an interesting paper
  in the IJ, to go ahead and sign up for the "Adopt-a-Paper" program,
  so that in the following weekend she/he moves the code into the
  Code/Review directory ?


A tempting place, could be the IJ itself, (as a link to click on?)

...or .... even better

the paper itself !,

We could add a footnote to every page, where the invitation to join
the "Adopt-This-Paper" is reinstated.


It will be pretty easy to add such footnote, and it will remind readers
that they are a fundamental piece of the ITK Open Source community.


Suggestions ?


    Luis


--------------------------------------------------
On Fri, Feb 20, 2009 at 7:44 AM, Dan Mueller <dan.muel at gmail.com> wrote:

> Hi Insight Developers,
>
> I have a question regarding the procedure for contributing new classes
> and algorithms to ITK.
>
> Of late it seems there has been a number of additions directly to the
> Code/Review/ folder, bypassing the procedure listed here:
>
> http://www.itk.org/Wiki/ITK_Procedure_for_Contributing_New_Classes_and_Algorithms
>
> (Perhaps my perception of the matter is wrong, in which case I'd be
> happy to be corrected).
>
> As a developer I can definitely see the advantages of directly
> submitting code to Code/Review: it is so much faster and easier. I
> have nearly a dozen little filters which I have been meaning to submit
> to the IJ (local maxima, local minima, scale/shift, vector
> shift/scale, cosine/hamming/lanczos/welch windowed since interpolate,
> power image filter, joint histogram), but have unfortunately never
> found the time. Other developers have found the time, yet these
> filters seem to languish there, in some cases for years, eg.
>    http://www.insight-journal.org/browse/publication/142
>
> Despite the perceived ease of directly submitting to Code/Review,
> obviously this diminishes the advantages listed here:
>
> http://www.itk.org/Wiki/ITK_Procedure_for_Contributing_New_Classes_and_Algorithms#The_Rationale
>
> My question: is there some way to strike a middle ground? Can
> "trivial" filters can be added directly to Code/Review/ after passing
> say a peer review via email, or something similar? Or perhaps there is
> an existing procedure for adding "trivial" filters to Code/Reivew/
> which I am unaware...?
>
> Of course, I am willing to help out whenever I can. I intend to submit
> more IJ reviews and act as a shepherd for papers (although for me the
> 3.0.12 release clashes with this year's MICCAI deadline).
>
> Just my two cents.
>
> Regards, Dan
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090220/e72ab2f5/attachment.htm>