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]