A few thoughts, followed by a summary of the discussion so far.
Ed Corrado noted some problems with peer review in an earlier message,
and I think those problems outweigh the gains of peer review -- which
ultimately amount to a little more respectability, mainly for those
seeking tenure. In that light, I like the open review process idea
suggested by Ed and Peter Binkley (editors vet the article; it's made
"available for public comment" for a limited period, perhaps in a wiki;
the author revises the article based on the comments; and the final
version gets published in a subsequent issue). Of course, this would
require commitment to comment/review from the larger community --
hopefully not just current code4lib folks, either -- but I think we can
pull that one off. If necessary, we could even have a designated,
rotating group of reviewers/commenters ("peer review lite"?). You
should also be able to post anonymous comments, for the same reason that
peer reviewers are usually not identified.
Regarding whether to publish as a formal journal: Some people on the
list and in-channel have expressed reservations about issuing all the
articles as issues (i.e. in regular chunks rather than as they are
written). But there's no reason we couldn't publish finalized articles
early, as "pre-releases" between issues, just so long as the final
version eventually gets published as part of a regular issue. In fact,
this would dovetail nicely with the editorial process described above.
One approach would be to have a regular publication schedule with its
own "official release" RSS feed, while any articles that are finalized
before publication can also be released early via a separate "as-ready"
feed.
More generally, I think there are good arguments for having an ISSN,
regular publication, and an established review process with clear and
public editorial policies (whatever the process itself might be). These
things lend legitimacy and authority to the project, and those are good
qualities that we want to have.
***
To add to Peter Binkley's summary of the emerging consensus, I think
we've also agreed on the following:
* The core audience for the journal would be the more-or-less-hardcore
coders and developers, plus any "accidental techs" willing to
participate in hardcore-type conversations.
* The emphasis would be on the practical, with actual code and specific
solutions to problems -- as Eric Lease Morgan says, "code snippets,
hacks, Javascript widgets & gadgets, etc." This could be balanced by
some higher-level "feature articles" as well.
* Comments would be enabled on all articles. Dorothea Salo's "I tried
this and it
worked!" button would complement this nicely.
* The journal MUST reach out to people beyond the current code4lib
community. Several people have said this is a good argument in favor of
a more formal structure.
* There has to be a low barrier to participation. I think the shorter
articles can serve this function, since they would have a fairly simple
editorial process. It needn't be much more difficult than writing a
substantial, rigorous blog post. The editors could even solicit
articles from bloggers ("Hey, that post was interesting -- want to get
it published?").
* Several people have offered to host the journal at their institutions
using Open Journal Systems. If we want to be more informal or
experimental than OJS will allow, the existing code4lib.org site would
be a natural home.
--
Jeff Davis
Public Services Librarian
University of Alberta Libraries
[log in to unmask]
IM screen name: jd4v15 (MSN, AIM, Yahoo)
-----Original Message-----
From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
Binkley, Peter
Sent: Wednesday, February 22, 2006 11:38 AM
To: [log in to unmask]
Subject: Re: [CODE4LIB] A code4lib journal proposal
I agree with Ed Corrado that the purpose of the peer-review process is
to improve the articles, not to give thumbs-up or thumbs-down. How about
making the review process consist of submitting an article into a wiki
(with proper discussion page etc.) and letting it simmer there for a
while before moving it to the more formal journal area?
I think getting the dynamic-content part right will be the hard part.
I'm always frustrated by the problem of comments in blogs: often they're
as important as the postings, but how do you track them? Subscribe to a
separate comments RSS feed (as you have to do on my blog)? Have the main
entry appear as new in the main RSS feed every time someone posts a
comment (as Art's blog does, I believe)? Neither of these really gets me
engaged with the discussion the way I (sometimes) want to be. If the
journal is going to be truly edgy, we need a better solution than
anything I've run into.
We seem to be forming a consensus that the journal would consist of
different things, including:
1) formal articles, things that might otherwise have gone to D-Lib or
Ariadne
2) short how-tos / lessons learned pieces, like lightning talks, ideally
sparking a string of comments and additions like Art's shepherd's pie
recipes
3) hacks: actual code
How about demos? Should we aim to have the server-side capacity and
facilities to actually show new stuff in operation? A lot of this would
have a limited shelf-life (in that we wouldn't undertake to maintain the
code), but it would be nice to have a single place where you could see
some eye-candy.
Peter
Peter Binkley
Digital Initiatives Technology Librarian
Information Technology Services
4-30 Cameron Library
University of Alberta Libraries
Edmonton, Alberta
Canada T6G 2J8
Phone: (780) 492-3743
Fax: (780) 492-9243
e-mail: [log in to unmask]
|
