andrew@calvin.doc.ca (Andrew Patrick) (02/28/91)
This is an official Call for Votes for the proposed newsgroup
"comp.sources.reviewed". "Comp.sources.reviewed" will be a moderated
newsgroup (moderator: Andrew Patrick [andrew@calvin.doc.ca]) with the
following charter:
"Comp.sources.reviewed" is a moderated newsgroup for the
distribution of program sources that have been subjected to a Peer
Review process. Similar to the process used for academic
journals, submissions are sent to a moderator who then sends the
sources to Peer Review volunteers for evaluation. The Reviewers are
asked to provided a timely evaluation of the software by compiling
and running it on their machine. If time does not permit them to
complete a review, they are responsible for asking the moderator to
select another reviewer. If the Moderator and Peer Reviewers judge
a submission to be acceptable, the sources will be posted along with
the written comments provided by the Reviewers. If a submission is
not found to be acceptable, the submitter will be provided with the
Reviewers' comments, and they will have the option of addressing
those comments and submitting the sources again.
Volunteers interested in reviewing sources for this newsgroup can
send a note to "reviewed@calvin.doc.ca" to be placed on the list.
Votes for and against this proposed group should be sent to
votes@calvin.doc.ca
Please specify in your Subject: line if you vote yes or no by including
the words "yes" or "no" somewhere in the line, and then include in the
body a clear statement of your preference:
e.g., "I vote YES for comp.sources.reviewed."
or
e.g., "I vote NO for comp.sources.reviewed."
The voting period will last from Feb. 28 1991 to March 31 1991.
Technical Information on Reaching "calvin.doc.ca"
-------------------------------------------------
"Calvin.doc.ca" is an Internet site that should be easily reachable
from any network. For those who need more detailed information:
The host "calvin.doc.ca" is directly connected to the Internet and uses
an MX forwarder called "dgbt.doc.ca" (also known as "dgbt.crc.dnd.ca")
(192.12.98.7).
"calvin.doc.ca" is also reachable by UUCP using a path like:
...uunet!mnetor!lsuc!nrcaer!dgbt!calvin!votes
--
Andrew Patrick, Ph.D. Department of Communications, Ottawa, CANADA
andrew@calvin.doc.CA
"The interface IS the program."kent@sparky.IMD.Sterling.COM (Kent Landfield) (03/01/91)
In article <1991Feb28.053121.7739@rick.doc.ca> andrew@calvin.doc.ca (Andrew Patrick) writes: >This is an official Call for Votes for the proposed newsgroup >"comp.sources.reviewed". "Comp.sources.reviewed" will be a moderated >newsgroup (moderator: Andrew Patrick [andrew@calvin.doc.ca]) with the >following charter: > > "Comp.sources.reviewed" is a moderated newsgroup for the > distribution of program sources that have been subjected to a Peer > Review process. Similar to the process used for academic > journals, submissions are sent to a moderator who then sends the > sources to Peer Review volunteers for evaluation. Question: What types of packages are you envisioning on reviewing ? Packages like elm, mush, perl, ... have their own beta test groups who usually do a solid job of testing their software. For that matter, any software that has a beta test team would probably not need or have any reason to post through this group. Question: Are you planning on accepting any type of software running on unix, dos, coherent, minix, acorn, amiga ...? Or will this be focused for a specific operational environment? How will you locate enough reviewers for packages that run in other than the major environments. Question: What happens when you cannot find enough people to review the package ? Is the submission rejected ?? Are we going to be seeing a lot of "requests for reviewers" on the net ? Question: This whole thing seems to have started as an emotional reaction to delays in postings to c.s.unix. What are the expected time delays in submissions through this group ?? Just the setup to evaluate a package by your description is going to take a bit of time. The review by multiple people will take time. [ Even the reviewers have real jobs... :-) ] If there are any questions, problem etc., that will take more time. My guess is that you are looking at a 45 to 60 day delay on the optimistic side. Doesn't this procedure usually take 6 to 9 months for submissions to be accepted and published in academic journals ?? I can see that there could be a use for this group but I don't think that there has been enough discussion for a real call for votes. In the discussion period I have seen a grand total of 5 articles on the topic and three of them have come from Andrew Patrick [andrew@calvin.doc.ca]. If we are going to do this, lets do it right. There has not been enough discussion to warrant a vote. My intention here is to try to get some information and to stimulate a discussion so that any vote is based on merit and not emotion... -Kent+ -- Kent Landfield INTERNET: kent@sparky.IMD.Sterling.COM Sterling Software, IMD UUCP: uunet!sparky!kent Phone: (402) 291-8300 FAX: (402) 291-4362 Please send comp.sources.misc-related mail to kent@uunet.uu.net.
dwh@ataritx.uucp (Dave Hanna) (03/01/91)
In article <1991Feb28.160555.8446@sparky.IMD.Sterling.COM> kent@sparky.IMD.Sterling.COM (Kent Landfield) writes: >In article <1991Feb28.053121.7739@rick.doc.ca> andrew@calvin.doc.ca (Andrew Patrick) writes: >>This is an official Call for Votes for the proposed newsgroup >>"comp.sources.reviewed". >Question: This whole thing seems to have started as an emotional reaction >to delays in postings to c.s.unix. What are the expected time delays in >submissions through this group ?? Just the setup to evaluate a package >by your description is going to take a bit of time. The review by multiple >people will take time. [ Even the reviewers have real jobs... :-) ] If >there are any questions, problem etc., that will take more time. My >guess is that you are looking at a 45 to 60 day delay on the optimistic >side. 45 to 60 days sounds like a reasonable guess. What are delays running through comp.sources.unix now? I want to be careful how I come into this debate. I appreciate the job that Rich $alz is doing, and that it's a tough job. I also appreciate that the comp.sources groups are not an "inalienable right" to which I am entitled, and am thankful for what does come out of them. On the other hand, I can appreciate the frustration of authors [and potential users] of a piece of software that submit it to comp.sources.unix and then wait for seemingly interminable and unpredictable periods of time and see nothing come out. I don't know what the actual delays from submission to posting are, because Rich doesn't choose to tell us what has been submitted and is in the queue. I know the monthly posting for Elm says that several patches have been submitted to comp.sources.unix, and that none have yet appeared. I've been using Elm for at least six months, and it was at patch level 6 when I started, so I would guess that some of those patches have been in the queue for many, many months. (And they have been beta tested before they are submitted.) The point of this is, if we can get a mechanism that will produce archiveable sources with a fairly predictable 45-60 day delay, I'm all for it. > -Kent+ >-- >Kent Landfield INTERNET: kent@sparky.IMD.Sterling.COM >Sterling Software, IMD UUCP: uunet!sparky!kent >Phone: (402) 291-8300 FAX: (402) 291-4362 >Please send comp.sources.misc-related mail to kent@uunet.uu.net. -- Dave Hanna Atari Microsystems Corp UUCP ...!texsun!letni!ataritx!dwh ...!ames!atari!dhanna
karsten@tfl.dk (03/01/91)
In article <1991Feb28.160555.8446@sparky.IMD.Sterling.COM>, kent@sparky.IMD.Sterling.COM (Kent Landfield) writes: > In article <1991Feb28.053121.7739@rick.doc.ca> andrew@calvin.doc.ca (Andrew Patrick) writes: >>This is an official Call for Votes for the proposed newsgroup >>"comp.sources.reviewed". "Comp.sources.reviewed" will be a moderated >>newsgroup (moderator: Andrew Patrick [andrew@calvin.doc.ca]) with the >>following charter: >> >> "Comp.sources.reviewed" is a moderated newsgroup for the >> distribution of program sources that have been subjected to a Peer >> Review process. Similar to the process used for academic >> journals, submissions are sent to a moderator who then sends the >> sources to Peer Review volunteers for evaluation. > > Question: What types of packages are you envisioning on reviewing ? > Packages like elm, mush, perl, ... have their own beta test groups > who usually do a solid job of testing their software. For that matter, > any software that has a beta test team would probably not need or have > any reason to post through this group. Those packages submitted to the moderator would be reviewed if possible. > Question: Are you planning on accepting any type of software running > on unix, dos, coherent, minix, acorn, amiga ...? Or will this be focused > for a specific operational environment? How will you locate enough > reviewers for packages that run in other than the major environments. I know many would like the group to be one operating system only, but USENET can be carried on other operating systems. This is written on VAX/VMS. Currently we got a group for reviewed UNIX software, but none for other operting systems. There should be a group for other operating systems. Many of the bested public domain packages have been ported from UNIX to other operating systems, and some the other way. In the future, we can expect people will comply with the posix standards, which will supported on many operating systems. So in the future packages will not be for one operating system. For these reasons it would be stupid to limit the group to one or a few operating systems. > Question: What happens when you cannot find enough people to review the > package ? Is the submission rejected ?? Are we going to be seeing a lot > of "requests for reviewers" on the net ? There would be no alternative to rejecting such packages, and ask the submitter of the code to post it to some other group. My guess is that "reguest for reviewers" will be rare because most public domain software is written for a few popular operating systems. Andrew has already 20-30 reviewers. > Question: This whole thing seems to have started as an emotional reaction > to delays in postings to c.s.unix. What are the expected time delays in > submissions through this group ?? Just the setup to evaluate a package > by your description is going to take a bit of time. The review by multiple > people will take time. [ Even the reviewers have real jobs... :-) ] If > there are any questions, problem etc., that will take more time. My > guess is that you are looking at a 45 to 60 day delay on the optimistic > side. Doesn't this procedure usually take 6 to 9 months for submissions > to be accepted and published in academic journals ?? Journals use paper mail for transporting papers. After the paper has been reviewed, it must be typeset, and proff read. These things takes time. Besides, papers for conferences are normally reviewed in a few months. The moderator will need ca 1 week for assigning moderators and submitting the code to the reviewers. The reviewers could use one month, and the moderator one week for collecting the results and taking action. That's 6 weeks, and You must admit that both the moderator and the reviewers have been given enough time. It would of course take more time in case the code has to be corrected, and so what? Then the whole USENET won't vaste time on installing a collecting of bugs. > I can see that there could be a use for this group but I don't think that > there has been enough discussion for a real call for votes. In the > discussion period I have seen a grand total of 5 articles on the topic and > three of them have come from Andrew Patrick [andrew@calvin.doc.ca]. If > we are going to do this, lets do it right. There has not been enough > discussion to warrant a vote. My intention here is to try to get some > information and to stimulate a discussion so that any vote is based on > merit and not emotion... Perhaps. I have only seen a posting raising the first point of your posting, i.e., which operating systems should be supported. Have I missed some postings, or why didn't You raise the other points in the period of discussion? > -Kent+ > -- > Kent Landfield INTERNET: kent@sparky.IMD.Sterling.COM > Sterling Software, IMD UUCP: uunet!sparky!kent > Phone: (402) 291-8300 FAX: (402) 291-4362 > Please send comp.sources.misc-related mail to kent@uunet.uu.net.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (03/02/91)
In article <1991Mar1.082855.149@tfl.dk> karsten@tfl.dk writes: > Journals use paper mail for transporting papers. After the paper has > been reviewed, it must be typeset, and proff read. These things takes > time. And you're implying that since comp.sources.reviewed will use e-mail instead, it will run smoothly? Be serious. Referees have always been and will always be the biggest bottleneck in journal publication. ---Dan
karsten@tfl.dk (03/03/91)
In article <4989:Mar123:50:0391@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > In article <1991Mar1.082855.149@tfl.dk> karsten@tfl.dk writes: >> Journals use paper mail for transporting papers. After the paper has >> been reviewed, it must be typeset, and proff read. These things takes >> time. > > And you're implying that since comp.sources.reviewed will use e-mail > instead, it will run smoothly? Be serious. Referees have always been and > will always be the biggest bottleneck in journal publication. > > ---Dan No I am implying that when it runs smoothly, it can be faster than journal publication. Noboby can tell in advance wheither or not the referees of comp.sources.reviewed would be bottleneck, but I think that the moderator of c.s.r could easily find a substitute a slack referee. Andrew has already 20-30 applicant for the posts as referees. I addition, the referees will work faster because they know the system could be fast. So is the human mind. No single person will have as much work with running c.s.r as R$ has with comp.sources.unix, even if c.s.r get a larger throughput, and it will be much easier to replace those who are slack. Karsten Nyblad TFL, A Danish Telecommunication Research Laboratory E-mail: karsten@tfl.dk