Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!haven!mimsy!mojo!mojo!djm From: djm@eng.umd.edu (David J. MacKenzie) Newsgroups: comp.sources.d Subject: Re: v01INF3: Submit - Submission Guidelines for comp.sources.reviewed Message-ID: Date: 12 Apr 91 03:06:35 GMT References: <1991Apr11.023044.2643@rick.doc.ca> <9979:Apr1122:30:4291@kramden.acf.nyu.edu> Sender: news@eng.umd.edu (C-News) Organization: Project GLUE, University of Maryland Lines: 90 In-Reply-To: brnstnd@kramden.acf.nyu.edu's message of 11 Apr 91 22:30:42 GMT In article <9979:Apr1122:30:4291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: If this group is only going to accept software that works under BSD, System V, MS-DOS, the Mac OS, VMS, and VM/CMS (just to name a few), it won't get many submissions. I don't follow that. Don't most Internet users use those systems most of the time, and most submissions to existing groups run on those systems? > Please use an informative "Subject" line when mailing postings. > Something like "nlist - New file list utility, Part01/04" Uh-oh. I can see the first few packages coming through now... Yes, please rename submissions that have names that conflict with existing programs that do something different! > Each submission should include the following types of files. ``Types of files''? You mean not necessarily under those names? Some authors prefer ReadMe, Install, or readme.doc, install.doc . . . doesn't make much difference, does it? (Well, uniformity is nice if you want to find all the documentation at a glance.) This point should be clarified, though, whichever way. > but many users prefer that they be able to make > and test software in the current directory before they install it. Is there anyone who doesn't prefer this? I really like packages that have a separate installation script; make does not work well for files in different directories, and I hate having privileged operations hidden inside a Makefile. make -n doesn't work well enough? It seems to be sufficient for me. I agree that it's nice to be able to test something without having to install it. Complex packages with lots of support files should probably support an environment variable or similar mechanism specifying the root(s) of the directories they use. Otherwise you have to build it twice -- one time configured for a test location, then again configured for the final installation location. > The preferred form for patches is "diff" > format, using the "-c" option to produce context diff files. The preferred form should be unidiff. Good idea. It would save a lot of bandwidth over time. The unidiff-aware patch program is easy to get from lots of ftp and uucp archive sites. Or it could even be posted to the newsgroup. Maybe GNU diff too. > - if submission is accepted: > - moderator discusses evaluations with author > - moderator posts sources and evaluations This is supposed to be modelled on traditional journal reviews, but reviewers don't get anonymity, and reviews are published. What a joke. I don't recall whether the group's charter mentions this issue. I don't know how closely the group ought to follow the traditional journal review model; what is most appropriate for this medium? > We are discouraging making repairs to submissions during the review > process. Ahahahahaha. That's funny. I agree; I think having the reviewers give the authors feedback, and getting fixes from the authors for problems they find, would probably speed up and improve the reviewing process significantly. > Once the reviews are completed, you will receive a summary from the > moderator, and, if necessary, will have a chance to make repairs to > your package. So will the package be re-reviewed after that? That could entail a long cycle of submit-review-fix-submit-review-fix etc. if authors aren't allowed to interact with reviewers. Consider the reviewers "post-beta" testers, and the submissions will probably make it through the pipeline more quickly, without loss of quality. Maybe with a gain in quality. Of course, that would eliminate the reviewers' anonymity, unless you interpose the group's moderators as middlemen in all communication between authors and reviewers, stripping "From: " lines before passing on the reviewers' comments. -- David J. MacKenzie