Xref: utzoo news.groups:28422 comp.sources.d:6604 Newsgroups: news.groups,comp.sources.d Path: utzoo!utgpu!cunews!dgbt!rick.doc.ca!calvin.doc.ca!andrew From: andrew@calvin.doc.ca (Andrew Patrick) Subject: Re: CALL FOR VOTES -- comp.sources.reviewed Message-ID: <1991Mar4.221334.2436@rick.doc.ca> Summary: discussion about policy and operation Keywords: news groups source review Sender: news@rick.doc.ca Nntp-Posting-Host: calvin.doc.ca Organization: Communications Research Centre, Ottawa References: <1991Feb28.160555.8446@sparky.IMD.Sterling.COM> <1991Mar1.150759.11832@rick.doc.ca> <1991Mar3.035928.28569@sparky.IMD.Sterling.COM> Date: Mon, 4 Mar 1991 22:13:34 GMT In article <1991Mar3.035928.28569@sparky.IMD.Sterling.COM> kent@sparky.IMD.Sterling.COM (Kent Landfield) writes: >In article <1991Mar1.150759.11832@rick.doc.ca> andrew@calvin.doc.ca (Andrew Patrick) writes: >> >>NOTE: I am restricting this discussion to news.groups: > >Many people feel that this should be discussed in comp.sources.d since that >is the area which we are discussing. For my postings, I added it back... OK. ... >An additional area that need clarification is how patches going to be >dealt with. Will they go back through c.s.r for re-evaluation prior >to being posted? Or will patches be accumulated prior to resubmission >through c.s.r ? Given that as of one week ago I thought this proposal was not going to fly, I haven't done a lot of thinking on this. Also, I do not want to be responsible for setting all the policy for this group. You will be the users of the group -- those of you who submit sources and those of you who use them. Therefore, it should be you who makes these kinds of decisions. I can give you my opinions on these issues, and I encourage others, especially those who have agreed to be reviewers, to discuss what you want to see. Concerning patches, I envision enlisting the help of one or more associates who will be responsible for maintaining an archive and quickly testing and distributing patches. I imagine that when patches come in, they will be quickly tested against the software in the archive and then distributed ASAP. I also foresee complete re-posts of packages once a fair number of patches have been applied, especially if the posting traffic is light (e.g., while waiting for reviews of new sources to come in). >I would like to suggest that a more indepth description of the group's >general procedures and proposed policy be posted. Yes, I know that this >is beyond what is needed to vote but some of us think the vote is just a >formality... :-) You could consider it a headstart on the introduction >and policy posting ... :-) From a submitters perspective, how are authors to >submit and work with the group, how will the group deal with the inevitable >patches, and what are areas that would cause rejections are a good starting >place. These are real areas that will have to be addressed. Now is as good >a time as any... :-) :-) Again, I can only give you my opinions on these issues: Concerning the relationship between the author and the group of reviewers, I imagine it will go something like this: - author submits source to moderator - moderator assigns source to reviewers - reviewers return comments (based one some guidelines) to moderator - moderator makes posting decision based on reviews - if accepted: - moderator prepares summary of reviews to be attached to posting - moderator discusses summary with author - moderator posts sources and summary of reviews - if rejected: - moderator prepares summary of reviews to be returned to author - moderator discusses reviews with author - moderator may suggest that sources be revised and re-submitted - moderator may suggest alternate place for sources I do not foresee any direct contact between the reviewers and the author, and I think it might be a good idea for the reviewers to remain anonymous, but that is something to be discussed by you. Concerning criteria for acceptance, this will have to be worked out. Also, I think the criteria will have to evolve somewhat as we see what kinds of sources are submitted. Obviously, one criteria will have to be that it is a well-formed package: that is has README, Makefile, and patchlevel files, man pages, installation instructions, etc. The installation procedure is also an obvious area of evaluation. The sources will also have to be evaluated for portability, as much as possible. Did it compile on a variety of machines (at least those it was intended for)? This test for portability I see as one of the hardest things to conduct, and I am not sure how to do it. Obviously, selecting reviewers that run on a variety of platforms will be a first step. Another area of evaluation will have to be operation -- did it run smoothly, or are their obvious problems and bugs. Also, are their obvious shortcomings that could be fixed to produce a much better package. In summary, I don't know what I have gotten myself into (some would say a pile of SH*T), but I think it is an idea who's time has come. I hope that WE can work out the policy and operation of the group, and make it a valuable resource for both the authors and the users. -- Andrew Patrick, Ph.D. Department of Communications, Ottawa, CANADA andrew@calvin.doc.CA "The interface IS the program."