[alt.sources.wanted] CALL FOR VOTES -- comp.sources.reviewed

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