[Insight-developers] IJ Volunteers
Gaëtan Lehmann
gaetan.lehmann at jouy.inra.fr
Fri Sep 22 10:12:24 EDT 2006
Hi,
Le Fri, 22 Sep 2006 00:43:48 +0200, Julien Jomier
<julien.jomier at kitware.com> a écrit:
> Hello,
>
> I think the recent posts regarding the IJ have been very constructive
> and I want to give you a brief overview of the current status of the IJ
> and some improvements we have been implementing in the past few days.
>
> Among the new features, the possibility to add associate editors and
> have them select/invite reviewers has been added. Now editors and
> associate editors can invite reviewers and reminders are sent via email
> (I usually tend to forget my reviews if I don't get a reminder ;)).
>
> Following Torsten's email, I started to implement (almost finished) a
> new way to submit revisions using subversion. Basically authors will be
> able to access their submissions using SVN and make modifications and
> even share the repository with other users and submit the modified code
> to the testing system. The idea is that once the code is stable, the
> user will mark it as a new revision and it will be published on the IJ.
Really really nice :-)
Even better if we can test the code on the automatic testing system before
submitting the contribution to the journal.
How will the be managed the permissions ?
>
> Next on the todo list is related to Zach's comments regarding the
> selection of papers to be moved into the toolkit. The IJ will provide a
> way to associate a "shepherd" for a given publication. The shepherd will
> be responsible for moving the code into the toolkit. That should provide
> an easy way to look at the current status of a submission.
great :-)
>
> I plan to post a full list of new features related to the IJ when I'm
> done but I wanted to keep you posted.
>
> We/I really appreciate your comments, suggestions and criticisms (that's
> how everything evolves right? :)) on the Insight Journal.
>
> Thanks,
>
> Julien
>
> Zachary Pincus wrote:
>> So I've been thinking about the relationship between the IJ and ITK for
>> the last few days now.
>> I think there's no reason to suspect that the IJ has been a failure in
>> any of its goals -- except getting user-provided reviews for
>> ITK-targeted submissions. It provides a good repository of code people
>> can use (and, hopefully, have been using). The design documents that
>> make up IJ submissions are very useful to have for any user of the
>> code, and especially if that code is to be integrated into ITK.
>> Finally, there are a lot of great code submissions on it right now.
>> That, coupled with Stephen's report about IJ working really well for
>> the MICCAI process makes me feel pretty good about the mechanism as a
>> whole. The only snag is that for some reason there are fewer user
>> reviews than hoped. And this even wouldn't be a huge problem except
>> that the mechanism for inclusion in ITK is predicated on number of
>> reviews.
>> All in all, I think the IJ is the right way to go forward with making
>> ITK a self-sustaining project. There are just some minor tweaks that
>> need to be made, which could include:
>> (1) Change the way that IJ submissions are considered for ITK
>> inclusion. Grassroots-acclaim in terms of many positive reviews should
>> still be a valid method (and may be used more in the future as the IJ
>> picks up steam), but while it does so (and in case it does not), there
>> should be other options.
>> Perhaps a more traditional method (like most open-source projects use)
>> could be considered: someone proposes some new functionality (in this
>> case, by putting it on the IJ). Then they ask about it on the developer
>> list, and if there are a few 'ayes' from the list and no 'nays', then
>> one of the devs with commit priviliges (presumably one of the 'aye'
>> voters, or the feature-proposer him or herself) could add it. I'm
>> really not sure that I see anything wrong with this approach -- it
>> works for a lot of other projects, and it still uses the IJ pretty
>> integrally.
>> Or if something more "democratic" sounds good, perhaps there could be
>> quarterly polls where people vote for their favorite IJ features that
>> should be included. This is lighter-weight than getting reviews, and
>> might get more use. Top vote-getters could be reviewed by interested
>> parties, or just directly discussed on the dev list.
>> (2) Figure out how to get more reviews. Clearly in the MICCAI case,
>> people were incentivized to write reviews for many reasons: to learn
>> about new science, to participate in a conference, etc. Equally
>> clearly, there are fewer incentives to write reviews for the IJ.
>> I had one suggestion -- correctly criticized by Torsten -- about
>> requiring people to write reviews before they can get their own IJ
>> submissions integrated into ITK. This is clearly lame, because it's no
>> fun to have to do even more work (on top of an IJ submission) to give a
>> gift. However, it's also lame to give a gift and have nobody use it
>> because it didn't get reviews. So while this proposal might not be the
>> best, perhaps there are other good ideas for having better incentives
>> to review code.
>> Also, I still think that including some/all of the IJ code in a
>> special dir within ITK might help expose run-of-the-mill ITK users to
>> the IJ, and might help solicit reviews.
>> Zach
>> On Sep 17, 2006, at 3:26 PM, Luis Ibanez wrote:
>>
>>>
>>> Hi Zach,
>>>
>>>
>>> I have to admit being trapped in the chicken-egg fallacy of my own
>>> argument.
>>>
>>>
>>> Your are right, there is indeed a group of developers who steers
>>> the direction of ITK.
>>>
>>>
>>> These developers, however, are aware that it is not up to them to
>>> setup the direction of the toolkit. That such decisions must be
>>> driven by the needs and interests of the community at large.
>>>
>>>
>>>
>>> The challenge that this group of developers faced two years ago was:
>>>
>>> How to transfer that steering power to the community?
>>>
>>>
>>> ...with the goal of bringing ITK to become a self-sustained system.
>>>
>>>
>>>
>>> Setting up the IJ system was an attempt to bootstrap that process of
>>> power transfer to happen. Here is how the wild dream was supposed to
>>> unfold:
>>>
>>>
>>> 1) Create an electronic Online Open resource
>>>
>>> 2) Give everybody access to Publish and to Review contributions
>>>
>>> 3) Empower contributors with a community resource where they
>>> can post their source code, data, parameters, experiences.
>>>
>>> 4) Let the community decide what contributions were good enough
>>> to go permanently into the toolkit, via public reproducible
>>> reviews of that material.
>>>
>>> 5) Grow the group of developers to include contributors of
>>> source code.
>>>
>>>
>>>
>>> In that scenario, the steering committee was supposed to do less and
>>> less, and let the community do more and more. The older developers
>>> were supposed to just make sure that the wheels of the system were
>>> turning, and providing support for new developers that were not
>>> familiar with all the details of the software.
>>>
>>>
>>>
>>> What we have learned, however, is that Freedom is an privilege that
>>> not everybody wants to exercise. That most people are still more
>>> comfortable with letting others make decisions for them. That they
>>> are still used to higher authorities doing the thinking for them.
>>>
>>>
>>>
>>> The avalanche of user-provided reviews
>>> that we were expecting...
>>> have not happened.
>>>
>>>
>>>
>>> Why ?
>>>
>>>
>>> ...It is hard to tell at this point...
>>>
>>>
>>>
>>> Maybe because we didn't provided enough education and motivation
>>> to the users to convince them of the advantages of exercising
>>> their right to make decision on the future of the toolkit.
>>>
>>>
>>> Maybe because the real meaning of peer-review is still contaminated
>>> with the decadence of a structure that today is only used for
>>> deciding if an academic should be hired, funded, promoted or fired.
>>> At at the end, nobody really cares about the content of what is
>>> being published. whether it works or not, whether it is true or not,
>>> as long as the so necessary credits are admonished to the authors by
>>> the review process.
>>>
>>>
>>> Maybe because the concept of "Publishing" never really conveyed
>>> the idea that the purpose is to share results with the community.
>>> And most users are still addicted to submitting to reputation-based
>>> journals in order to get the academic credits their need for their
>>> annual reports.
>>>
>>>
>>> Maybe it was a mistake to attempt to solve two different problem:
>>>
>>> a) The need for an honest peer-review publication system
>>> b) The need for adopting contributions to the toolkit
>>>
>>>
>>> With a single answer:
>>>
>>>
>>> and online Open Access, Open Review publication system
>>>
>>>
>>>
>>> The fact that we are going through all this discussion among
>>> the group that was supposed to have a clear idea of how the
>>> system was intended to work is an unsettling evidence that
>>> this probably wasn't such a good idea after all.
>>>
>>>
>>> On the bright side, we still have the comforting option that we
>>> can go back to reading IEEE-TMI the papers that were submitted two
>>> years ago, reviewed anonymously without any attempt for verifying
>>> reproducibility, and we can go back to writing code that reimplements
>>> algorithms by reverse engineering a verbal description scattered
>>> through papers. Enjoy the detective work of fishing for those untold
>>> values of parameters that make the difference between success and
>>> failure when running an algorithm.
>>>
>>>
>>>
>>> The fact that Biologist were ready to embrace Open Access and
>>> online publishing doesn't mean that computer scientists were
>>> ready for living up to the same standards.
>>>
>>>
>>>
>>>
>>> Luis
>>>
>>>
>>>
>>>
>>> ========================
>>> Zachary Pincus wrote:
>>>> I don't think anyone is suggesting that there is a small circle of
>>>> "all-powerful developers". However, there is a circle of developers,
>>>> who, in an admirably open fashion, minister to ITK. This circle is
>>>> overseen by the ITK Oversight Committee ( http://www.itk.org/Wiki/
>>>> ITK_Oversight_Committee ).
>>>> It was some subset of these developers and the oversight committee
>>>> who decided upon (again in an open fashion) the precise algorithm
>>>> for transferring work from the IJ to ITK, and the exact parameter
>>>> settings for that algorithm. (Of which there are many! What's the
>>>> threshold of review-goodness for accepting a work? How many reviews
>>>> are needed? Are works from old "editions" of the IJ re-visited?)
>>>> Thus, when Gaëtan suggested a change to some of the algorithm
>>>> settings, it is reasonable and natural that that suggestion be sent
>>>> to the itk-dev list, where, by and large, the people who decided
>>>> upon the algorithm and settings (in an open and democratic fashion)
>>>> and may continue to refine them, can be reached. Before today's
>>>> emails, I would have presumed that the open nature of ITK would
>>>> encourage suggestions of this sort.
>>>> Again, to review:
>>>> There is a problem in getting work from the IJ to ITK via the
>>>> algorithm sketched below. This can be addressed by:
>>>> (a) addressing at the algorithm. In which case, addressing the
>>>> people involved in setting and changing that algorithm is
>>>> appropriate.
>>>> (b) addressing the IJ. In which case, "complaining" to the itk-dev
>>>> list is not appropriate, but volunteering to do reviews, to be an
>>>> associate editor, and many other such things *is* appropriate.
>>>> Gaëtan and I think that perhaps (a) *and* (b) need to be addressed.
>>>> And I find it wholly inappropriate to castigate him, repeatedly and
>>>> publicly, about failing to do the right things, regarding (b), when
>>>> in fact his concern was regarding (a) to begin with! (And not to
>>>> mention that few people have been doing more, (b)-wise, than he.)
>>>> Please do not conflate issues (a) and (b). I'll chalk this
>>>> misunderstanding up to the nature of email and language barriers.
>>>> Let me make some suggestions, regarding these separate issues:
>>>> Regarding (a):
>>>> - Perhaps three reviews is too many to require? A single review from
>>>> a highly-trusted source might be enough in some cases.
>>>> - Perhaps in cases when repeatedly-requested or otherwise desired
>>>> functionality for ITK is in the IJ, reviews could be directly
>>>> solicited.
>>>> - Perhaps during the quarterly review sessions, submissions that
>>>> appear to provide desired functionality but which lack reviews could
>>>> be noted and reviews requested. (Similar to above suggestion.)
>>>> - I don't know if submissions from "old editions" of the IJ are ever
>>>> re-visited. Perhaps they should be.
>>>> Regarding (b):
>>>> - I'm not sure what the point of the different "editions" of the
>>>> journal is. Why should time-of-submission matter at all? It seems to
>>>> serve to bury older work.
>>>> Regarding (a) and (b) together:
>>>> - Perhaps there isn't sufficient motivation for people like me to
>>>> write reviews? Maybe no submissions should be accepted in the ITK
>>>> unless the submitter has made three reviews of his or her own? This
>>>> might not provide the best kind of motivation (!), but it seems that
>>>> somehow making good reviews needs to be better-incentivized.
>>>> - I'd like to see more of the submissions put into the ITK
>>>> distribution somewhere under the "review" directory. Maybe if (1)
>>>> the submitter signs over the copyright, and (2) the buildbot can
>>>> build it, the submission could be deposited there.
>>>> You will note that most of these suggestions have to do with
>>>> procedure for ITK, or for the interaction of ITK and the IJ. Issues
>>>> which might best be discussed and resolved by the denizens of the
>>>> itk- dev list, and especially those on the oversight committee and
>>>> the cast of characters who makes up the regular conference-call
>>>> attendees.
>>>> Zach
>>>> On Sep 16, 2006, at 5:39 PM, Luis Ibanez wrote:
>>>>>
>>>>>
>>>>> Hi Gaëtan, Zach
>>>>>
>>>>>
>>>>> It seems that the fundamental misperception still remains
>>>>> in this discussion:
>>>>>
>>>>>
>>>>>
>>>>> The notion that there is a small circle of
>>>>> all-powerful "developers" who decides the
>>>>> destiny of the toolkit.
>>>>>
>>>>>
>>>>>
>>>>> That shows that the process for adding new code into ITK
>>>>> has not been communicated properly to the community.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The
>>>>>
>>>>> "...people in ITK developers who are choosing
>>>>> how to get code contributions in the toolkit..."
>>>>>
>>>>>
>>>>>
>>>>> is simply the following *Algorithm*:
>>>>>
>>>>>
>>>>> 1) Sort the contributions on the Insight Journal
>>>>> based on their ratings as provided by reviews.
>>>>> Reviews that are public and that can be posted
>>>>> by anybody.
>>>>>
>>>>>
>>>>> 2) Request copyright transfers of the source code
>>>>> to the Insight Software Consortium.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This means that the "readers/reviewers/raters" of papers
>>>>> in the Insight Journal are *the ones who decide* what
>>>>> gets included in the toolkit.
>>>>>
>>>>>
>>>>>
>>>>> There is nothing in this process that is closed or that
>>>>> excludes anybody.
>>>>>
>>>>>
>>>>> There are no different grades of "developers".
>>>>> There is no "root" user in ITK.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The fact that even though you have write access to the
>>>>> CVS repository, you will:
>>>>>
>>>>>
>>>>> "...not take the freedom to put in the
>>>>> toolkit all the nice work we can
>>>>> find in the IJ, even if cvs would
>>>>> let me do that..."
>>>>>
>>>>>
>>>>> Simply means that you are as responsible as all other ITK
>>>>> developers. We all share that same feeling and that same
>>>>> responsibility. And curiously enough, is this careful
>>>>> consideration and respect for the toolkit, one of the
>>>>> elements that makes so slow the process of integrating
>>>>> new code into the toolkit.
>>>>>
>>>>> In the same way that you will not dare to include code out of
>>>>> your own initiative, anyone of us older developers, will not
>>>>> dare either to make arbitrary unilateral decisions on what to
>>>>> include in the toolkit.
>>>>>
>>>>>
>>>>>
>>>>> It is not the fact that some "privileged group" of "developers"
>>>>> are the only ones that make arbitrary decisions on what to include
>>>>> in the toolkit. Instead, it is the fact that in order to include
>>>>> a piece of code into a toolkit that is used by a more than 2,000
>>>>> people in more than 40 different countries, and that should be
>>>>> maintained working for the next ten or so years, we want to get
>>>>> *at least* the opinions of *three* people by rating a contribution
>>>>> submitted to the Insight Journal.
>>>>>
>>>>>
>>>>> It is simply an *Open Process*
>>>>> that requires a *Participatory Community*.
>>>>>
>>>>>
>>>>>
>>>>> *EVERYTHING* about ITK is Open. Every document, from every
>>>>> meeting since 1999 is available on the Web. The agendas and
>>>>> minutes from every weekly conference are posted on the Wiki.
>>>>> The plans for releases, the bugs, the strengths and weaknesses
>>>>> of the toolkit. Everything is openly and publicly discussed.
>>>>>
>>>>>
>>>>> I would be surprised to find an Open Source project that has
>>>>> a more public and open process than ITK.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> That the process of moving source code
>>>>> from the Insight Journal to the Toolkit
>>>>> is slow....?
>>>>>
>>>>>
>>>>> YES,
>>>>>
>>>>>
>>>>> You are right. It is painfully slow.
>>>>>
>>>>>
>>>>>
>>>>> It was not supposed to be slow.
>>>>> It was not supposed to be painful.
>>>>>
>>>>>
>>>>>
>>>>> Why is it slow?
>>>>> and how it could be improved ?
>>>>>
>>>>>
>>>>>
>>>>> That's the *positive* discussion
>>>>> that we should be holding.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Luis
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ======================
>>>>> Gaëtan Lehmann wrote:
>>>>>
>>>>>> Hi Luis,
>>>>>> You're wrong, I'm not more a developer than before, and the write
>>>>>> access to ITK cvs is just shortening the time needed to fix some
>>>>>> bugs, but it doesn't make any difference regarding the code
>>>>>> contribution process. I will not take the freedom to put in the
>>>>>> toolkit all the nice work we can find in the IJ, even if cvs
>>>>>> would let me do that. That's something only you can do. "The term
>>>>>> developers" was surely badly chosen - please replace it with
>>>>>> something better, like "people in ITK developers who are choosing
>>>>>> how to get code contibutions in the toolkit".
>>>>>> For me, open access and peer review are an evidence: they are the
>>>>>> future of science publication. In the mean time, ITK is loosing a
>>>>>> part of its active community.
>>>>>> The red pill can be difficult to take if too few people are taking
>>>>>> it at the same time
>>>>>> Gaetan
>>>>>> Le Sat, 16 Sep 2006 21:06:53 +0200, Luis Ibanez
>>>>>> <luis.ibanez at kitware.com> a écrit:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi Gaetan,
>>>>>>>
>>>>>>>
>>>>>>> I would suggest that you approach this situation with a more
>>>>>>> positive
>>>>>>> attitude.
>>>>>>>
>>>>>>>
>>>>>>> You are referring to the IJ the same way a tax-payer will complain
>>>>>>> about the government.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Complaining and whining is not an effective strategy when you are
>>>>>>> trying
>>>>>>> to change the status quo of a community that has been mushy-
>>>>>>> minded by
>>>>>>> decades of "Publish or Perish" propaganda.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The Insight Journal *is not* an Institution,
>>>>>>> The Insight Journal *is* a Community Resource.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> There is no such a thing as "The Owners" of the Insight Journal.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> If you want to define such concept, probably the closest thing to
>>>>>>> the
>>>>>>> "Owners" of the Journal are the 1,200 subscribers to the ITK
>>>>>>> users list.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This is a Journal intended to be supported and managed by the
>>>>>>> community.
>>>>>>> This is why it is poised to be a real *peer-review* Journal.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The concept of "Freedom" is too new for our community, because the
>>>>>>> traditional peer-review process treats authors and readers as
>>>>>>> children
>>>>>>> who are supervised by the "adult" reviewers. The "adult"
>>>>>>> reviewers are
>>>>>>> the ones who decide what is good for the children to read. Such
>>>>>>> roles,
>>>>>>> atrophied critical thinking in the readers and lead them to
>>>>>>> passively
>>>>>>> accept any published paper as "absolute truth", because it has
>>>>>>> passed
>>>>>>> through the supposedly "holy" process of review by the "adults".
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Members of our community read technical journals with the same
>>>>>>> level
>>>>>>> of critical thinking that a watcher of TV-reality-shows exercise
>>>>>>> while
>>>>>>> sitting empty-minded for hours in front of the TV-set. The
>>>>>>> concept that
>>>>>>> they are actually entitled to question the content of papers is too
>>>>>>> alien for them. The notion that a published paper may contain
>>>>>>> mistakes,
>>>>>>> is a sacrilege for them. The notion that the claims made in a paper
>>>>>>> are supposed to be verified, is a blasphemy to them.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> After all,
>>>>>>>
>>>>>>> "Who are readers to question the judgment of the holy
>>>>>>> reviewers" ?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> As a consequence our community has developed the laziness of the
>>>>>>> kid
>>>>>>> that doesn't do his homework until the parents tell them to do so.
>>>>>>>
>>>>>>>
>>>>>>> The concept that *everybody* is entitled to write a review, is
>>>>>>> too new
>>>>>>> for our community. Most readers and authors assume that
>>>>>>> "reviewing" is
>>>>>>> an activity exclusively reserved for some "supernatural" beings
>>>>>>> who are
>>>>>>> the "Chosen Ones", the "Holy Reviewers".
>>>>>>>
>>>>>>>
>>>>>>> Authors are still trained to submit papers to Journals and "Pray"
>>>>>>> for
>>>>>>> the papers to be accepted by the "Chosen Ones".
>>>>>>>
>>>>>>>
>>>>>>> It takes a lot of education, motivation and *repetition* to
>>>>>>> rehabilitate
>>>>>>> readers and authors from the damage that the "Publish or Perish"
>>>>>>> disease
>>>>>>> has inflicted on their minds.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> In the meantime,
>>>>>>> You are discharging your frustration on the wrong crowd.
>>>>>>>
>>>>>>>
>>>>>>> Instead of complaining about the management of the Journal and its
>>>>>>> supposed "Owners", you should brainstorm on ways of encouraging all
>>>>>>> under-graduate and graduate students to act as reviewers. They
>>>>>>> should
>>>>>>> learn that they *ARE* qualified to be reviewers. They should
>>>>>>> learn that
>>>>>>> they *are* the "PEERS" that the term "Peer-Review" refers to:
>>>>>>>
>>>>>>>
>>>>>>> It is not "Supervisor-Review"
>>>>>>> It is not "Nobel-Prize-Review"
>>>>>>> It is not "Chosen-One-Review"
>>>>>>> It is not "Friend-of-The-Journal-Editor-Review"
>>>>>>> It is not "Owner-of-The-Journal-Review"
>>>>>>> It is not "Anonymous-Competitor-Review"
>>>>>>>
>>>>>>>
>>>>>>> It is "PEER-Review"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Definition of "PEER":
>>>>>>>
>>>>>>> One that is of equal standing with another :
>>>>>>> EQUAL; one belonging to the same societal group
>>>>>>> especially based on *age*, *grade*, or *status*
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The "PEERS" of Graduate Students are *OTHER GRADUATE STUDENTS*.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *EVERY* person that uses ITK *IS* qualified to act as a
>>>>>>> reviewer
>>>>>>> of the Insight Journal.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> There is no need for being "Friend" of anybody.
>>>>>>> There is no need for being consecrated through some "Holy
>>>>>>> Process".
>>>>>>> There is no need for belonging to some influence group.
>>>>>>> There is no need for being member of any social circle.
>>>>>>> There should not be a need to be pressured by an associate
>>>>>>> editor.
>>>>>>>
>>>>>>>
>>>>>>> That is the message that we must pass across the community.
>>>>>>>
>>>>>>> Having 1,200 users in the mailing list, there is no shortage of
>>>>>>> brains for reviewing less than 100 papers.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Do not make the mistake of thinking
>>>>>>> that the Insight Journal is simply the
>>>>>>> gate for bringing source code into ITK.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The Insight Journal is the RED PILL that may help our community
>>>>>>> to wake up from THE MATRIX of the "Publish or Perish" stratagem.
>>>>>>>
>>>>>>>
>>>>>>> As a community resource, the *Exercise of participating* in the
>>>>>>> review
>>>>>>> process is *MORE* important than the act of bringing code into ITK.
>>>>>>>
>>>>>>>
>>>>>>> It is a simple matter of teaching readers to stand on their own
>>>>>>> feet,
>>>>>>> to judge with their own minds, and to take responsibility for their
>>>>>>> own future.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> "Publish or Perish" was invented by budget managers and
>>>>>>> administrators
>>>>>>> who didn't wanted, or were incapable of understanding the science
>>>>>>> they
>>>>>>> were managing. It was an easy trick that made possible for them to
>>>>>>> "count numbers of papers" in an annual report instead of having to
>>>>>>> "read those papers" and try to understand their implications.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We as a community, are all guilty of nourishing this primitive and
>>>>>>> decadent practice. We still assume that "number of papers" equals
>>>>>>> "productivity", regardless of what the paper content is.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> As dogs in training, the "Publish or Perish" stratagem, educated
>>>>>>> our
>>>>>>> community members to receive cookies (productivity credits) when
>>>>>>> they
>>>>>>> bark (publish), no matter what the barking was about. In the
>>>>>>> "Publish
>>>>>>> or Perish" MATRIX, there are no cookies for the ones who listen
>>>>>>> to the
>>>>>>> barking (read the publications). There are no cookies for the
>>>>>>> ones who
>>>>>>> attempt to repeat the barking of others (reproduce publications).
>>>>>>> Only
>>>>>>> "original barking" is supposed to be worth of cookies.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The Insight Journal is like a public library. It is there, open for
>>>>>>> everybody. However, we can not force people to go to this library,
>>>>>>> we can not force people to contribute reviews.
>>>>>>>
>>>>>>>
>>>>>>> The challenge we face at this point is to untrain the damage that
>>>>>>> years
>>>>>>> of traditional publishing system has made. Every time that we hear
>>>>>>> a
>>>>>>> senior researcher telling a junior researcher "You should
>>>>>>> publish" we
>>>>>>> must jump in alert and examine "WHY" and "HOW" publishing should be
>>>>>>> done.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> You are now *an ITK developer*, at this point, you have access to
>>>>>>> all
>>>>>>> the same resources and information that any other "ITK developer"
>>>>>>> has.
>>>>>>> You have write access to the CVS repository, access to the mailing
>>>>>>> lists, access to the Wiki, access to the bug tracker. As you can
>>>>>>> see
>>>>>>> there is no magic aura that suddenly appears, no sparkly dust
>>>>>>> falling
>>>>>>> down while you walk. It is just one more entry among many other
>>>>>>> things
>>>>>>> in your to-do list.
>>>>>>>
>>>>>>>
>>>>>>> You can complain about other "ITK developers" not doing enough, but
>>>>>>> that's not going to make the world move any faster. The place where
>>>>>>> you could invest your energy in a positive way is by going to all
>>>>>>> junior researchers around you and letting them know that "Publish
>>>>>>> or
>>>>>>> Perish" is a lie, and that if they don't take responsibility for
>>>>>>> the
>>>>>>> quality of work shared in their community, nobody else will. At
>>>>>>> least
>>>>>>> nobody without an agenda of their own...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Luis
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> =======================
>>>>>>> Gaëtan Lehmann wrote:
>>>>>>>
>>>>>>>> Stephen,
>>>>>>>> Have I said or done something wrong ?
>>>>>>>> I'm writting a review for each new paper I'm able to review -
>>>>>>>> perhaps I'm late of 1 review or 2 - but I'll not submit 3
>>>>>>>> reviews per paper, and will not submit reviews for my own ones.
>>>>>>>> I'm asking about reviewer associate because their role is to
>>>>>>>> assign some reviewers to a paper, and most of the papers in
>>>>>>>> the IJ are still lacking of reviews - Note that I'm only
>>>>>>>> talking about the contributions to ITK, not about the articles
>>>>>>>> for the MICCAI. I would be pleased to incite potential
>>>>>>>> reviewers to write more reviews, but again, I have seen
>>>>>>>> nothing about the editor associate since your last mail.
>>>>>>>> Alsso, it seem that the ITK developers are not getting that
>>>>>>>> letting a contribution for 6 or 9 months in the insight
>>>>>>>> journal without much activity is like saying
>>>>>>>> "we don't care about your work and the time you spent to
>>>>>>>> write your article".
>>>>>>>> If there can't be more reviewers for the contributions to the
>>>>>>>> insight journal, do not require 3 reviews to integrate it in
>>>>>>>> the toolkit, are stop asking people to post their code to the
>>>>>>>> IJ. If you (developers) really don't care, just keep things
>>>>>>>> like that - that's fine.
>>>>>>>> Some days like this one, I'm really not sure why I'm still
>>>>>>>> using the IJ, and warning their owners about what is wrong -
>>>>>>>> it also look like a huge waste of time
>>>>>>>> Gaetan
>>>>>>>> Le Sat, 16 Sep 2006 01:52:17 +0200, Stephen R. Aylward
>>>>>>>> <Stephen.Aylward at kitware.com> a écrit:
>>>>>>>>
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> Thanks for volunteering to provide more reviews! There are
>>>>>>>>> instructions on the wiki on how to write reviews and
>>>>>>>>> contribute to the IJ.
>>>>>>>>> As each new paper arrives - I am assigning it to reviewers, but
>>>>>>>>> we always welcome additional reviews.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Stephen
>>>>>>>>>
>>>>>>>>> ___
>>>>>>>>> Sent with SnapperMail
>>>>>>>>> www.snappermail.com
>>>>>>>>>
>>>>>>>>> ..... Original Message .......
>>>>>>>>> On Fri, 15 Sep 2006 22:34:56 +0200 Gaëtan Lehmann
>>>>>>>>> <gaetan.lehmann at jouy.inra.fr> wrote:
>>>>>>>>>
>>>>>>>>>> Le Mon, 21 Aug 2006 18:19:37 +0200, Stephen R. Aylward
>>>>>>>>>> <Stephen.Aylward at Kitware.com> a écrit:
>>>>>>>>>>
>>>>>>>>>>> Thanks for all who have already volunteered to be Associate
>>>>>>>>>>> Editors for
>>>>>>>>>>> the Insight Journal!
>>>>>>>>>>> http://insightsoftwareconsortium.org/wiki/index.php/IJ-Whos-Who
>>>>>>>>>>>
>>>>>>>>>>> We are still looking for a few more volunteers. You've
>>>>>>>>>>> contributed
>>>>>>>>>>> code to open-source medical image analysis...why not help to
>>>>>>>>>>> spread the
>>>>>>>>>>> news of your contribution and the contributions of others...
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> What is the status of this initiative ?
>>>>>>>>>> I've seen nothing about it since this mail, and there is lots of
>>>>>>>>>> contributions in the IJ which again will not get their 3
>>>>>>>>>> reviews before
>>>>>>>>>> the sept 20 (http://www.itk.org/Wiki/ITK_Release_Schedule).
>>>>>>>>>> If things stay
>>>>>>>>>> like that, some of them will be more than one year old without
>>>>>>>>>> getting
>>>>>>>>>> their 3 reviews.
>>>>>>>>>> If things stay like that, lots of contributors will be
>>>>>>>>>> discouraged
>>>>>>>>>>
>>>>>>>>>> Believe me, I'm a contributor
>>>>>>>>>>
>>>>>>>>>> And what a waste of time.
>>>>>>>>>> If things have been done earlier, some classes can have been
>>>>>>>>>> integrated in
>>>>>>>>>> the toolkit 2 releases ago
>>>>>>>>>>
>>>>>>>>>> Gaetan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -- Gaëtan Lehmann
>>>>>>>>>> Biologie du Développement et de la Reproduction
>>>>>>>>>> INRA de Jouy-en-Josas (France)
>>>>>>>>>> tel: +33 1 34 65 29 66 fax: 01 34 65 29 09
>>>>>>>>>> http://voxel.jouy.inra.fr
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Insight-developers mailing list
>>>>> Insight-developers at itk.org
>>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>> _______________________________________________
>>>> Insight-developers mailing list
>>>> Insight-developers at itk.org
>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>
>>>
>>>
>>> _______________________________________________
>>> Insight-developers mailing list
>>> Insight-developers at itk.org
>>> http://www.itk.org/mailman/listinfo/insight-developers
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
--
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66 fax: 01 34 65 29 09
http://voxel.jouy.inra.fr
More information about the Insight-developers
mailing list