Well, since I brought up the idea at code4libcon, I'm in favor of it
:-). I'm not sure how the best way to handle the review process would
be, but I do know that tradition blind peer review would:
a) Be a lot of work
b) Slow down the process (which is a problem with a journal such as
c) Not work because the community is so small, it would be pretty
easy to figure out who
wrote it (or at least limit it to a few possibilities) anyway,
so it wouldn't really be blind.
Someone (Ross?) mentioned we already have a few journals such as DLib,
Adriane and ITAL. Well, that may be true, but when I look at them I see
mostly big formal projects being written about. I think a code4lib
journal could provide an outlet for small projects and hacks... Things
that a single systems librarian in a smaller library setting can do in
his or her "free" time between going to meetings and staffing the
reference desk. For those who were at code4libcon, a good example of the
type of articles I'm picturing is the Lipstick on a Pig presentation by
Jim Robertson. I don't picture it only being articles like that, but I
do picture that being an outlet for smaller projects like what Jim has
done. I also like the idea of including code snippets and reports on
failed attempts. Really, you can often learn more from reading what
didn't work then reading about what did.
I was thinking about a possible review process while/after talking to
people at code4lib. One idea that came up was that the pre-reviewed
articles can go up, and that anyone in the community can review them and
make comments (sort of like Art's recipes that were passed around the
small village) for a set period of time, and then the author(s) can make
changes. It can then be given a "go" to be published or sent back for
more review and/or revisions. Obviously, this would need to be hashed
out much more. For example, what is the "community," how exactly to
submit comments, who gives the final "go" to consider it accepted, etc.
But this is one possibility.
Well, that is my two cents worth,