Andrew Patrick <csr@calvin.doc.ca> (04/11/91)
Submitted-by: Andrew Patrick <csr@calvin.doc.ca>
Posting-number: Volume 1, Info 1
Archive-name: Status
Comp.sources.reviewed is now an official moderated newsgroup, and the
"newgroup" control message has been posted. (If you are not familiar
with the purpose of comp.sources.reviewed, see the Introduction message
in a companion posting.) The contact address for comp.sources.reviewed
is "csr@calvin.doc.ca".
There has been a lot of activity "behind-the-scenes" among the reviewers
in getting the newsgroup setup. We are now ready to accept, review, and
post sources. A set of Guidelines for Submissions is contained in a
companion posting. We expect that these Guidelines will be revised from
time to time as we get into the review process, so your comments are
always welcome.
It looks like the official archives for comp.sources.reviewed will be
housed on uunet.uu.net, in a format similar to that used by the other
comp.sources.* groups.
We would like to thank Kent Landfield, Rich Salz, Andrew Partan, and
Steve Kinzler (among others) for providing their software and/or
assistance. Their generosity has helped in getting this group set-up.
--
Andrew Patrick acting as Comp.Sources.Reviewed Moderator
Department of Communications, Ottawa, CANADA
csr@calvin.doc.CAbrnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/12/91)
Should the referenced message (originally in comp.sources.reviewed as well) have been cross-posted here? I don't think so, but I'm not sure. (I know it should have had Followup-To: comp.sources.d.) In article <1991Apr11.022612.2522@rick.doc.ca> csr@calvin.doc.ca (Andrew Patrick) writes: > There has been a lot of activity "behind-the-scenes" among the reviewers > in getting the newsgroup setup. Of course. So all the people who voted for the group are now getting a group that may only loosely correspond to what was proposed at first. This isn't a flame, just an observation. ---Dan
jik@athena.mit.edu (Jonathan I. Kamens) (04/12/91)
In article <9418:Apr1121:48:4291@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: |> In article <1991Apr11.022612.2522@rick.doc.ca> csr@calvin.doc.ca (Andrew Patrick) writes: |> > There has been a lot of activity "behind-the-scenes" among the reviewers |> > in getting the newsgroup setup. |> |> Of course. So all the people who voted for the group are now getting |> a group that may only loosely correspond to what was proposed at first. |> This isn't a flame, just an observation. It is an observation that has no basis in reality, and sounds like more of your illogical flaming about this newsgroup. The "behind-the-scenes activity" Andrew is referring to is the ironing out of the administrative details which will allow the submission and review process to operate effectively, AS IT WAS PROPOSED. The activity referred to was conducted within the framework of WHAT WAS PROPOSED. What reason do you have to believe that just because the reviewers talked about the newsgroup in E-mail, it will not provide the functionality that was proposed in the charter upon which the Usenet voted? Or are you saying that the various people who have agreed to be reviewers for the group are not allowed to correspond with each other in private E-mail, because the mere act of doing so makes them somehow unable to meet the charter of the group? -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
jfh@rpp386.cactus.org (John F Haugh II) (04/12/91)
In article <9418:Apr1121:48:4291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <1991Apr11.022612.2522@rick.doc.ca> csr@calvin.doc.ca (Andrew Patrick) writes: >> There has been a lot of activity "behind-the-scenes" among the reviewers >> in getting the newsgroup setup. > >Of course. So all the people who voted for the group are now getting >a group that may only loosely correspond to what was proposed at first. >This isn't a flame, just an observation. How, pray tell, do you reach this conclusion? Don't get me wrong, I didn't vote for the group either. But it seems to me that some amount of "behind the scenes" work has to occur for just about anything that is set up on the net, simply because this isn't real life - we aren't working in the same office building and can't "watch" everything that goes on. I will probably never submit anything to the group. It seems pointless and redundant and spiteful. You want feedback and testing - use alt.sources as your beta-test facility, then pick one of the other groups for the finished product. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "If liberals interpreted the 2nd Amendment the same way they interpret the rest of the Constitution, gun ownership would be mandatory."
scs@iti.org (Steve Simmons) (04/12/91)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <1991Apr11.022612.2522@rick.doc.ca> csr@calvin.doc.ca (Andrew Patrick) writes: >> There has been a lot of activity "behind-the-scenes" among the reviewers >> in getting the newsgroup setup. >Of course. So all the people who voted for the group are now getting >a group that may only loosely correspond to what was proposed at first. >This isn't a flame, just an observation. And one with no basis in fact. We're ironing out the rules on notifying submitters, when reviewers have to get data back to the moderators, etc, etc. Purely administrative. Note the "we". I speak from facts, not guesses. -- "Our informal mission is to improve the love life of operators worldwide." Peter Behrendt, president of Exabyte. Quoted in Digital Review, Feb 4, 1991.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/13/91)
In article <scs.671464069@hela.iti.org> scs@iti.org (Steve Simmons) writes: > brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >Of course. So all the people who voted for the group are now getting > >a group that may only loosely correspond to what was proposed at first. > >This isn't a flame, just an observation. > And one with no basis in fact. We're ironing out the rules on notifying > submitters, when reviewers have to get data back to the moderators, etc, > etc. Purely administrative. Note the "we". I speak from facts, not > guesses. Oh, really? I suppose that the difference between unpublished, anonymous reviews and published, credited reviews is ``purely administrative''? Or are you going to claim that you're not considering such a change? Sorry, but that isn't ``ironing out the rules'' like the twiddling in your examples. The fact is that the basic workings of the group were not settled before the vote, and you're only now making up rules that will entirely determine the nature of comp.sources.reviewed. Again, I don't mind this; I didn't vote for the group, so I'm not going to feel cheated if it ends up wildly different from the original proposals. What I do mind is that you're pretending to have modelled the process on journal publication. I wonder how many of the comp.sources.reviewed reviewers have ever been referees, let alone editors, of professional or academic journals---especially since the current c.s.r rules have almost nothing in common with those of any established publication. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/13/91)
In article <19199@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > In article <9418:Apr1121:48:4291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >Of course. So all the people who voted for the group are now getting > >a group that may only loosely correspond to what was proposed at first. > >This isn't a flame, just an observation. > How, pray tell, do you reach this conclusion? The reviewers are still arguing even the most basic issues: anonymity and publication of reviews. Sure, they need to work privately to iron out details and write up appropriate guidelines and organize the group's first big review, but they should feel some responsibility towards the people who gave them a place to show some results. > I will probably never submit anything to the group. It seems pointless > and redundant and spiteful. You want feedback and testing - use > alt.sources as your beta-test facility, then pick one of the other > groups for the finished product. Yeah. I keep trying to figure out what c.s.r would do for any of my code that alt.sources and Brandon/Kent and Rich wouldn't or didn't do. I keep coming up with the same answer: longer lead times. Yay. ---Dan
nolan@helios.unl.edu (Michael Nolan) (04/14/91)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >Oh, really? I suppose that the difference between unpublished, anonymous >reviews and published, credited reviews is ``purely administrative''? >I didn't vote for the group, so I'm not going to feel cheated >if it ends up wildly different from the original proposals. >What I do mind is that you're pretending to have modelled the process on >journal publication. I wonder how many of the comp.sources.reviewed >reviewers have ever been referees, let alone editors, of professional or >academic journals---especially since the current c.s.r rules have almost >nothing in common with those of any established publication. Well, Dan, I have served as a referee for a professional journal, have served as the graduate assistant for an editor of a professional journal, have served as the editor for a publication (not a refereed one, though), and have also written reviews of software which were published in the computer trade papers under my byline. I've written articles for refereed publications which have been subjected to the reviewing process. I have also served as a beta tester for computer software. I have also followed the c.s.r group from the first tentative CFD some six months or so ago. Incidentally, that first post called for the creation of a reviewing process like that used for professional journals, so the insistence of anonymity for those reviewers who desire it should not come as much of a shock. Personally, as a reviewer for c.s.r, I don't feel that anonymity is much of an issue for me, and I've said as much in the discussion within the c.s.r reviewers on the drafting of the guidelines. It may well be that after the group is created it is discovered that anonymity is a non-issue. The guidelines (as I interpret them) permit individual reviewers to choose whether or not they desire to remain anonymous. I think the problem here is that the c.s.r discussion becamed muddled with that concerning Rich Saltz and the periodic comp.sources delays. I really don't want to rekindle that flame feud, and I see c.s.r as an alternative means of code distribution, not as a replacement. There are currently two or three alternatives to comp.sources, c.s.r is just another option. I don't have a copy of the guide for reviewers for a refereed periodical handy at present, but I could lay my hands on one if necessary. As I recall them, though, they seem to have the same spirit as c.s.r, although the process is different because of the distribution system. What do you find different that isn't related to the distribution system? So you didn't vote for c.s.r. Big deal. You lost. If you don't want to participate in it, unsubscribe to the group and don't submit any sources to it. (You _do_ submit sources to the net, don't you?) ------- Michael Nolan This is my .sig Internet: nolan@helios.unl.edu T*His_iS#MY%.SIg oN DrUGs!@%#@% UUCP: tssi!nolan Any questions?
csr@calvin.doc.ca (Andrew Patrick as CSR Moderator) (04/14/91)
In article <16831:Apr1306:25:0591@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >The reviewers are still arguing even the most basic issues: anonymity >and publication of reviews. Sure, they need to work privately to iron >out details and write up appropriate guidelines and organize the group's >first big review, but they should feel some responsibility towards the >people who gave them a place to show some results. Publication of the reviews has never been a point of discussion -- it was included in the original charter, and nothing has changed. Reviews will be published along with the software. The anonymity of the reviewers has been discussed, with the result being that reviewers will remain anonymous unless then wish to reveal themselves. This is what the reviewers wanted. -- Andrew Patrick acting as Comp.Sources.Reviewed Moderator Department of Communications, Ottawa, CANADA csr@calvin.doc.CA
jik@athena.mit.edu (Jonathan I. Kamens) (04/15/91)
In article <16390:Apr1305:56:2091@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: |> What I do mind is that you're pretending to have modelled the process on |> journal publication. I wonder how many of the comp.sources.reviewed |> reviewers have ever been referees, let alone editors, of professional or |> academic journals---especially since the current c.s.r rules have almost |> nothing in common with those of any established publication. It is my impression that Dan is arguing that the moderator and reviewers of c.s.r are doing something improper, because they are claiming to model the newsgroup on the journal review process, when they don't know how that process actually works. Dan has further claimed that the people who voted for the newsgroup are therefore being cheated, because they voted for a newsgroup modelled on the journal review process, and that's not what they're getting. It seems to me that there is a fatal flaw in Dan's argument. It is very unlikely that, as a whole, the people who voted for the group know more about the "real" journal review process than the moderator and reviewers. Furthermore, when the group was being discussed, I think it was made quite clear how the moderator intended to run things. Therefore, it seems to me that what the voters were voting on were what they *thought* the group was going to be like, not what the "real" journal review process is like. If that's the case, then Dan, they're getting exactly what they voted for. In other words, if we said that we were going to do things like an academic journal, and the people who voted "yes" for the group have the same idea as we do about how academic journals do things, then they're getting what they voted for, even if we're all wrong about how academic journals actually work. In any case, I think all of this argument is stupid and useless. As I have recently pointed out to someone else in E-mail when discussing a newsgroup, groups do not always end up doing exactly what was specified in their charters, and this is not necessarily a bad thing. Now that the group has been created, if it provides a service that the Usenet as a whole finds useful, then it will flourish, and if it does not, then it will whither and die. My impression is that Mr. Bernstein seems to be saying that the people who voted for the group were not smart enough to understand what they were voting for. I find that assertion offensive. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/15/91)
In article <1991Apr14.190013.9991@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > It seems to me that there is a fatal flaw in Dan's argument. It is very > unlikely that, as a whole, the people who voted for the group know more about > the "real" journal review process than the moderator and reviewers. [ ... ] > My impression is that Mr. Bernstein seems to be saying that the people who > voted for the group were not smart enough to understand what they were voting > for. I find that assertion offensive. No. In fact, it is you, Mr. Kamens, who have explicitly made such an assertion. I find it rather funny that you can expose a ``fatal flaw'' in my argument by making a claim which, you later insist, is offensive. Even if everyone in the world knew everything about journal publication, it wouldn't have a whole lot to do with the group. The previously posted guidelines for comp.sources.reviewed have very little in common with journal publication except the general concept of a reviewer/referee. Perhaps they will change radically, but that would prove that the reviewers are failing to uphold their responsibility to the voters. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/15/91)
In article <nolan.671566523@helios> nolan@helios.unl.edu writes: > Incidentally, that first post called for the creation of a reviewing > process like that used for professional journals, so the insistence of > anonymity for those reviewers who desire it should not come as much of > a shock. The shock is that you would have even considered the opposite. It is exceedingly rare for a referee to give his name. Ever. And referee reports are NEVER published. Yet the original guidelines say this: : - reviewers return evaluations to moderator (based on guidelines : described an another document) : - moderator compiles evaluations and makes final publication decision : - if submission is accepted: : - moderator discusses evaluations with author : - moderator posts sources and evaluations Now I would almost believe that you didn't mean it this way: that the moderator not only compiles the evaluations, but removes all referee names from them, and that ``posts sources and evaluations'' was just a big typo for ``posts sources.'' But the guidelines go on: : Reviewers may contact you for information and clarification, Face it: this has absolutely nothing to do with journal publication. The editor is the author's sole contact; reviewers simply do not contact authors. Yet there is not a hint of the traditional anonymity in these guidelines. > There are currently two or > three alternatives to comp.sources, c.s.r is just another option. That's one of its biggest problems. > (You _do_ submit sources to the net, don't you?) Yes. I invite you---any of you---to explain what comp.sources.reviewed would have done for my latest package, volume24/yabbawhap in c.s.unix. Rich made no changes to it, so it's easy competition, right? Surely you can point out *some* advantage in your precious ``reviewing'' process. All I see is that c.s.reviewed would take weeks where Rich took days. ---Dan
jik@athena.mit.edu (Jonathan I. Kamens) (04/15/91)
In article <16831:Apr1306:25:0591@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: |> The reviewers are still arguing even the most basic issues: anonymity |> and publication of reviews. Sure, they need to work privately to iron |> out details and write up appropriate guidelines and organize the group's |> first big review, but they should feel some responsibility towards the |> people who gave them a place to show some results. If the people who voted for the newsgroup decide that it has not met their expectations, then they will not use it and it will whither and die. Dan, I do not believe that you are qualified to decide for all of those people whether or not the group is meeting their expectations. I believe that those people are the only ones who can decide whether their own expectations are being met. |> Yeah. I keep trying to figure out what c.s.r would do for any of my |> code that alt.sources and Brandon/Kent and Rich wouldn't or didn't do. |> I keep coming up with the same answer: longer lead times. Yay. I have had "lead times" of eight months in comp.sources.unix. I do not believe that c.s.r will ever have a program submitted and still not either posted or rejected eight months later. I have been told by Rich Salz that he would post a patch from me "in the morning," and then waited for six months without seeing that patch posted. Alt.sources has no moderation, no checking whatsoever. Obviously, c.s.r provides a service that it does not. Comp.sources.misc has not extensive checking of any sort, such as what Rich does; indeed, its charter states that the purpose of the moderation is pretty much only to make sure that non-source postings don't get posted there. C.s.r's review process, which will allow several people to get their hands on a program and knock the bugs out of it before those bugs are released all over the net, in my opinion provides something that comp.sources.misc does not. Finally, considering the recent performance in comp.sources.unix, it is my opinion that c.s.r has the potential to provide something that it does not -- more reliable, quicker service, and the ability to *guarantee* that service by making things more robust (with the large number of people working on the group, it is unlikely that all of them will suddenly find themselves unable to devote any time to it for six months). -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
oz@yunexus.yorku.ca (Ozan Yigit) (04/15/91)
In article <1991Apr14.190013.9991@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > My impression is that Mr. Bernstein seems to be saying that the people who >voted for the group were not smart enough to understand what they were voting >for. I really don't know how you could have formed that impression from what Dan actually wrote in public. Once can [on occasion] accuse Dan of many things, but not of under-handed double-talk. If he actually thought the voters were being stupid, he would have said so. I think he has clearly noted where he thinks there is a problem, and that does not include the voters. oz --- We only know ... what we know, and | Internet: oz@nexus.yorku.ca that is very little. -- Dan Rather | UUCP: utzoo/utai!yunexus!oz
jik@athena.mit.edu (Jonathan I. Kamens) (04/15/91)
In article <6338:Apr1420:14:1691@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: |> No. In fact, it is you, Mr. Kamens, who have explicitly made such an |> assertion. I find it rather funny that you can expose a ``fatal flaw'' |> in my argument by making a claim which, you later insist, is offensive. There is a difference between saying that people do not know how journals work, and saying that people do not know what they have voted for. You have claimed that the reviewers apparently don't know how "real" journals work. I have, for the sake of argument, accepted the validity of that claim (although other postings in this newsgroup disputed it). I have then gone on to point out that it is unlikely that the people voting for the gorup know any more about how "real" journals work than the reviewers. However, I then went on to explain that it is quite possible that the people voting for the newsgroup *think* they know how "real" journals work, or, at the very least, they think they know how the people proposing and participating in c.s.r intend for it to work. If their expectations agree with those of the moderator and reviewers, then they are getting what they paid for, so to speak. Now, it is YOU who have asserted that people aren't going to get what they have voted for, which seems to imply that you think they aren't intelligent enough to understand what they have voted for. I once again reject that assertion. I remain convinced that the people who voted for the newsgroup understood what was being proposed and voted for that. Whether or not what was being proposed was how "real" journals do things is irrelevant; if people understood the proposal and get what they thought they were getting, then the vote was completely legitimate. Do you have some evidence to back up your claim that people are not getting what they expected to get? If so, could you perhaps present it to us? Thus far, you seem to be the only person who is vehemently protesting the fact that people aren't going to get what they voted for. Also thus far, you have done little to prove this assertion. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
oz@yunexus.yorku.ca (Ozan Yigit) (04/15/91)
In article <1991Apr14.210953.12913@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > Now, it is YOU who have asserted that people aren't going to get what they >have voted for, which seems to imply that you think they aren't intelligent >enough to understand what they have voted for. No, it does not imply that at all. If you order over-easy, and get your eggs scrambled, that does not by default imply you did not know how to order eggs. oz --- What ought to disturb us are not mistakes | Internet: oz@nexus.yorku.ca in general, but only those of them that we | Uucp: utzoo/utai!yunexus!oz are powerless to correct. -- David Miller | Phone: 1+416-736-5257-33976
jik@athena.mit.edu (Jonathan I. Kamens) (04/15/91)
In article <6787:Apr1420:38:3991@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: |> Face it: this has absolutely nothing to do with journal publication. |> The editor is the author's sole contact; reviewers simply do not contact |> authors. Yet there is not a hint of the traditional anonymity in these |> guidelines. If a journal reviewer decides that there is something ambiguous or unclear in the paper he is reviewing, he may indicate that in his review, and the journal may decide that the ambiguity is severe enough that is has to be corrected (or, of course, they may decide that the paper should be rejected outright; but that isn't really relevant to the current discussion). At that point, the journal will forward the reviewer's comments back to the author, with all names removed (the anonymity that Dan is defending so vociferously), and the author has the opportunity to respond to the reviewer's comments if he feels they are incorrect, or to make corrections if he does not. (Note that you can replace "he" with "he/she" in the entire previous paragraph, and the rest of this posting where appropriate, if you are easily offended by such things.) The way we currently think we'll be doing things in c.s.r, the moderator will give no indication to the submitter of who the reviewers are. They will remain anonymous, unless they choose to contact the submitter directly. If they do not want to reveal themselves, and they need to contact the submitter to ask questions, they can do so through the moderator. Finally, any comments that the reviewers have that they think might help people will be included when the submission is finally posted to c.s.r. Mr. Bernstein appears to have three different problems (that I can see) with this proposed scheme. First of all, he objects to the idea of the reviewers ever contacting the submitter at all, anonymous or not. Second, he objects to the possibility of unanonymous communication between a reviewer and submitter. Third, he objects to the idea of reviewers' comments being published when the submission is posted. I see nothing wrong with reviewers contacting the submitter of a package. It seems no different to me from the forwarding of reviewers' comments back to the author in the case of a real journal, and I *know* that this happens, at least in some cases, because my sister is a biologist who has submitted several papers to several different journals and has, in several different cases, been given copies of reviewers' comments (with names reviewed) and asked to respond to them. The only difference, it seems, is that the c.s.r process will be iterative and responsive (i.e. a dialogue between the reviewers and the submitter), while the journal process is usually one-step (reviewer gets article, reviewer read article, reviewer writes evaluation, author gets copy of evaluation). This strikes me as an improvement over the journal review process, not a flaw. Now, as for the question of anonymity. Dan may turn out to be right -- we may end up deciding that it was a mistake to ever consider allowing reviewers to contact submitters and reveal their identities. However, thus far the only reason Dan has given for espousing this belief is that that's not the way real journals do things. In my opinion, that's not a very persuasive argument. If he would tell us why real journals do reviews anonymously, and then explain why he thinks those reasons apply equally in the case of c.s.r, I might be more convinced. It seems to me that there are several reasons for anonymity in real journals. First of all, you may end up reviewing an article written by a colleague, and you may not want that colleague to find out that it was you who panned his article and caused it to be rejected. Second, the colleague whose article you review today may end up reviewing one of your articles tomorrow, and if you give him a bad review today, he may do the same to you tomorrow as revenge (or, on the other hand, if you give him a good review, he may feel obligated to give you a good review even if you don't deserve it). The world of science is very competitive, and it seems to me that these and all the other reasons for anonymity are attempts to keep that competitiveness from contaminating the review process. I believe that the review process which we will undertake in c.s.r is *not* competitive, and was not meant to be. We do not have 100 programmers out there, all over the world, working on software in the same ground-breaking field, and competing with each other to be the first to publish their programs on the net. For the most part, when a submitter sends us something, he will probably be the only person working on anything like that, or one of the view, and it is very unlikely that he will have to feel a need to compete with other people working on similar projects. Furthermore, our criticisms will, for the most part, be of the "you have to fix these problems before this can be posted" variety, rather than of the "this program is utterly brain-damaged and we see no reason to post it to this newsgroup or any other variety" variety. What all this comes down to is that, in the majority of cases, there is *no need* for anonymity in the c.s.r reviewing process. In cases where there *is* a need for anonymity (for example in the latter case in the last sentence of the previous paragraph), it has been guaranteed, because reviewers need never contact the submitter directly. If Dan has some reason why he believes that anonymity in the c.s.r review process will be harmful despite what I have said above, I would like to hear it. If his only reason remains, "That's not how real journals do it!" then, like I have said, I remain unconvinced. |> > There are currently two or |> > three alternatives to comp.sources, c.s.r is just another option. |> |> That's one of its biggest problems. I've never understood this attitude. Why is giving people more options a problem? |> Yes. I invite you---any of you---to explain what comp.sources.reviewed |> would have done for my latest package, volume24/yabbawhap in c.s.unix. |> Rich made no changes to it, so it's easy competition, right? Surely you |> can point out *some* advantage in your precious ``reviewing'' process. |> All I see is that c.s.reviewed would take weeks where Rich took days. First of all, Dan, as I am sure you are aware, arguments of this sort from the specific to the general hold very little water. You cannot argue that because one package would not have benefitted from c.s.r, no packages can benefit from c.s.r. The fact that you are attempting to do so seems to me to cast doubts on your ability to come up with better arguments against c.s.r. In any case, the c.s.r reviewing process may have found typos in your documentation. It may have found unanticipated OS dependencies that needed to be removed. It may have found bugs you were not aware of. It may have found any number of problems that neither you or I can anticipate. Since you seem to think you know so much about the review process in real journals, you must know that it is not intended only for the reviewers to find the problems that the author knows about; it is intended for the reviewers to find any problems that may be there, including ones that the author may not have anticipated. Therefore, to answer your question -- the c.s.r review process may have found problems that you did not anticipate. Now, you can argue, "But there were none!" but that's like saying that the journal review process is unnecessary because all submitters of papers to journals can guarantee to the journal in advance that their papers have no problems in them. I will give you two counter-examples in response to your one example. The "chemtab" package, as originally posted to comp.sources.unix, had so many problems that I could not install it on my system when I got it. The configuration options didn't, and the compile-time options didn't. I have talked to Rich Salz privately about this, and he has told me, "Chemtab was a mistake." C.s.r would not, in my opinion, have allowed that mistake to happen. After all, I could very well have been one of the reviewers, in which case I would have caught the problems *before* it was posted, in the review phase, rather than *after* it was posted, which is what happened when it was posted to c.s.u.. Another example is my "delete" package. When the whole comp.sources.unix flame war was happening in news.admin, I expounded at length about the problems I had with my package and comp.sources.unix. I have talked about that with Rich Salz too, and he has acknowledged that he made mistakes with my package and apologized (an apology I accepted willingly; I think Rich is a great guy, and I certainly don't think that anything he did was intentional or typical). I truly believe that *none* of the problems I had with my package in c.s.u would have occurred had I posted it to c.s.r. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
nolan@helios.unl.edu (Michael Nolan) (04/15/91)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >The shock is that you would have even considered the opposite. It is >exceedingly rare for a referee to give his name. Ever. And referee >reports are NEVER published. Again, having served as a referee, as a graduate student for a very well published professor, and having had prospective papers reviewed, there is often a chinese wall between the author and the reviewer. Face it, in most academic disciplines the editor tends to send articles to referees knowledgeable in that area, and quite often they are well-known to the original author. I've been present when my professor, in reading the reviewers report, recognized both the writing style and the viewpoints of several reviewers. (And later discussed the comments with them at a conference where they freely acknowledged being the reviewers.) The author is generally supposed to be anonymous to the reviewers, but that is seldom actually the case. (The simple rule is to count the number of papers cited. The author is often the most cited source.) The question of publishing the reviews, or of the reviewer contacting the author are potentially significant issues. A mechanism which permits the reviewer to contact the author directly while maintaining anonymity should not be all that difficult to implement via a relay service maintained by the moderator of c.s.r. (I see virtually no way to ensure that the author is anonymous to the reviewers, though.) I'm not sure about the desirability of 'publishing' the reviews yet, but I could see either method (publishing or not publishing) having value. My cynical side has always suspected that the REAL reason why the comments of the reviewers are not published is that it gives them an excuse to write another article. (Publish or perish, after all!) I'm not totally sure of that 'NEVER', though, because I think I've seen excerpts of reviews in the New England Journal of Medicine editorials. Michael Nolan nolan@helios.unl.edu
jik@athena.mit.edu (Jonathan I. Kamens) (04/15/91)
In article <22406@yunexus.YorkU.CA>, oz@yunexus.yorku.ca (Ozan Yigit) writes: |> In article <1991Apr14.190013.9991@athena.mit.edu> |> jik@athena.mit.edu (Jonathan I. Kamens) writes: |> |> > My impression is that Mr. Bernstein seems to be saying that the people who |> >voted for the group were not smart enough to understand what they were voting |> >for. |> |> I really don't know how you could have formed that impression from what |> Dan actually wrote in public. Do not assume that my impression of Dan's position on this issue has been formed solely on the basis of what he has written in public. He and I have exchanged E-mail about this. I will not quote at length from Dan's E-mail, because I do not believe it is fair to do that without asking him; I will say, however, that at one point he told me that he felt "shame" for the Usenet because it had allowed c.s.r to progress as far as it has. If he wishes to correct my impression of what he's saying, he can do so. |> Once can [on occasion] accuse Dan of many |> things, but not of under-handed double-talk. Actually, my impression of Mr. Bernstein is that he does, on occasion, indulge in "under-handed double-talk." I believe that much of what he has written about c.s.r can be characterized as "under-handed double-talk." |> If he actually thought the |> voters were being stupid, he would have said so. I think he has clearly |> noted where he thinks there is a problem, and that does not include the |> voters. What he has said is that c.s.r's advocates are claiming that it will be based on the journal review process, that people who voted for the group did so based on that assertion, that in fact c.s.r is *not* based on the journal process, and that therefore the people who voted for the group are not getting what they paid for. I believe that this argument implies that Dan does not believe the people who voted for the group are capable of judging exactly what they were voting for. I, on the other hand, believe that either (a) the people who voted for the group understood that when people said that c.s.r would be "based on" the journal review process, they meant that the basis would not necessarily be a one-to-one correspondence between what journals do and what c.s.r would do, or (b) the people who voted for the group have the same idea of how the relevant portions of the journal review process works as the group's moderator and reviewers. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
oz@yunexus.yorku.ca (Ozan Yigit) (04/15/91)
In article <1991Apr14.232818.15851@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > The way we currently think we'll be doing things in c.s.r, the moderator >will give no indication to the submitter of who the reviewers are. Jon, with all due respect, I (and most everybody else) already know at least two people who will be reviewers, just by the way they posted to this newsgroup. Good luck, folks. ;-) oz --- We only know ... what we know, and | Internet: oz@nexus.yorku.ca that is very little. -- Dan Rather | UUCP: utzoo/utai!yunexus!oz
jmaynard@thesis1.med.uth.tmc.edu (Jay Maynard) (04/15/91)
In article <1991Apr14.233634.16185@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > I, on the other hand, believe that either (a) the people who voted for the >group understood that when people said that c.s.r would be "based on" the >journal review process, they meant that the basis would not necessarily be a >one-to-one correspondence between what journals do and what c.s.r would do, or >(b) the people who voted for the group have the same idea of how the relevant >portions of the journal review process works as the group's moderator and >reviewers. One data point: I neither know nor care about the exact mechanics of peer- reviewed journals, as I'm exceedingly unlikely to ever submit an article to one. I read, understood fully, and voted for comp.sources.reviewed as proposed. This included an explicit decision that the group's mechanics as described in the proposal were a Good Thing. I'm truly at a loss to understand Dan's obvious vendetta against the group. What's wrong with another outlet for sources? We've seen the extremes of Rich $alz' response time in postings from Dan and Jonathan, ranging from a few days to several months. (No comment on Rich's performance as moderator is intended, as I do not have all the facts.) I believe that c.s.r will not achieve response times on the order of days, but neither will it take most of a year, as safeguards have been built into the process. Dan, if you don't like it, don't submit sources to it, but leave the rest of us alone while we make use of it. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jmaynard@thesis1.med.uth.tmc.edu | adequately be explained by stupidity. "X.400 is the mail system of the future, and I hope it stays that way." -- Erik E. Fair
jik@athena.mit.edu (Jonathan I. Kamens) (04/15/91)
In article <22409@yunexus.YorkU.CA>, oz@yunexus.yorku.ca (Ozan Yigit) writes: |> Jon, with all due respect, I (and most everybody else) already know at |> least two people who will be reviewers, just by the way they posted to |> this newsgroup. As someone else has pointed out in a recent posting in this newsgroup, in the scientific field you almost always have a good idea of which people a journal might choose to review your paper. In fact, when my sister's first paper was reviewed, her and the guy in charge of her lab managed to figure out who one of the reviewers was, because (according to her) he works in the same field as her in is a bit of an a**hole and panned her paper unfairly so that he would get to publish similar results before she could. There are almost 40 people currently in the queue to be able to review sources for c.s.r. If you submit a package for review, then unless you have a good idea of what kinds of sources each of them has volunteered to review, and of which of them are very busy and therefore unlikely to accept requests to review from the moderator, it is no more likely that you will be able to figure out *which* reviewers have been asked to review your submission than that you would be able to figure out which scientists have been asked to review an academic paper submitted by you to a journal. In fact, you are probably *less* likely to be able to figure it out in the case of c.s.r. The question is not one of complete anonymity; there are obviously a limited number of people who are qualified (and available) to review any particular c.s.r submission or journal submission. The question is one of degrees of anonymity -- how likely are you to be able to figure out who's doing the reviewing? The journal review process assumes that you won't be able to, but in many cases you can (there was a recent article in RISKS about a journal that sent the reviewer's comments to the author, but forgot to cut off the fax banner at the top of each page indicating the lab from which the comments were sent :-). The c.s.r review process will probably be no less successful than that at keeping reviewers anonymous if they want to be; indeed, if (as Dan seems to want) we are supposed to emulate a journal exactly, then we should publish a complete list of exactly what kinds of software each reviewer has signed up to review, so that submitters have a better chance of guessins who is doing their reviewing. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
john@iastate.edu (Hascall John Paul) (04/15/91)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: }Yes. I invite you---any of you---to explain what comp.sources.reviewed }would have done for my latest package, volume24/yabbawhap in c.s.unix. }Rich made no changes to it, so it's easy competition, right? Surely you }can point out *some* advantage in your precious ``reviewing'' process. As good as Rich is, he has limitations. He is only one person. He has only one set of world experiences. Doubtless, he has other demands on his time. And, perhaps most importantly, he (in all probability) has access to only a limited number of systems on which to test. -- John Hascall An ill-chosen word is the fool's messenger. Project Vincent Iowa State University Computation Center john@iastate.edu Ames, IA 50011 (515) 294-9551
john@iastate.edu (Hascall John Paul) (04/15/91)
oz@yunexus.yorku.ca (Ozan Yigit) writes: }jik@athena.mit.edu (Jonathan I. Kamens) writes: }> The way we currently think we'll be doing things in c.s.r, the moderator }>will give no indication to the submitter of who the reviewers are. }Jon, with all due respect, I (and most everybody else) already know at }least two people who will be reviewers, just by the way they posted to }this newsgroup. As I understand it, there are about 60 reviewers, only a few of whom will review any given submission. So, even if you knew all 60, you would be very unlikely to know which of those reviewed any given submission. -- John Hascall An ill-chosen word is the fool's messenger. Project Vincent Iowa State University Computation Center john@iastate.edu Ames, IA 50011 (515) 294-9551
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/15/91)
In article <1991Apr14.204213.12062@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > Finally, considering the recent performance in comp.sources.unix, it is my > opinion that c.s.r has the potential to provide something that it does not -- > more reliable, quicker service, and the ability to *guarantee* that service by > making things more robust Okay, I'm willing to believe that comp.sources.reviewed has the *potential* to provide (marginally) faster service than c.s.unix. Since this is its biggest (if not only) possible advantage, why don't you try to imitate a bit of what journals really do: put received, revised, and (if it matters) accepted dates on each article. If you commit yourself now to showing what your real delays are, you'll be able to look back in a few months and show me that I was wrong---if you have anything published in a few months, that is. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/15/91)
In article <1991Apr14.210953.12913@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > You have claimed that the reviewers apparently don't know how "real" > journals work. I asked whether any of them did because I didn't see any evidence at that point that they did. Apparently some of them do; I hope they have a hand in fixing the guidelines. > Do you have some evidence to back up your claim that people are not getting > what they expected to get? If so, could you perhaps present it to us? Sure. Journals do A. The current guidelines say B. You're considering changing the guidelines to A. There is absolutely no way that all the voters can be getting what they expected, unless they expected both A and B. I find it highly likely that some of the voters would be (e.g.) as shocked by the idea of publishing reviews as I was, if not more. Now it could be that people expected A, and you're going to end up with A, and B was just a big mistake. In that case I'm justified for flaming it, right? By the way, I didn't claim at first that people are not getting what they expected to get. I said that they *may* get something only loosely correlated with what they voted for. This is obviously true for any group that considers drastic changes after the vote. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/15/91)
In article <1991Apr14.232818.15851@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > At that > point, the journal will forward the reviewer's comments back to the author, > with all names removed (the anonymity that Dan is defending so vociferously), [ ... ] > The way we currently think we'll be doing things in c.s.r, the moderator > will give no indication to the submitter of who the reviewers are. They will > remain anonymous, unless they choose to contact the submitter directly. Fine. I'll accept that the guidelines really did mean that reviews will remain anonymous, though they say no such thing and imply exactly the opposite. > Finally, any comments > that the reviewers have that they think might help people will be included > when the submission is finally posted to c.s.r. Fine. I'll accept that ``moderator posts sources and evaluations'' really means ``moderator posts sources, along with any selected comments that the reviewers think might help people,'' rather than what it says. > I see nothing wrong with reviewers contacting the submitter of a package. It's not *wrong*, just extremely unusual. The guidelines say ``Reviewers may contact you for information and clarification''; the default in journal publication is that referees ask the editor to forward comments and questions. I'm glad you think you know what you're doing. Apparently that has very little to do with the guidelines. I suggest you hire a writer. > It seems no different to me from the forwarding of reviewers' comments back to > the author in the case of a real journal, and I *know* that this happens, I'm glad you know something about how journals work. > What all this comes down to is that, in the majority of cases, there is *no > need* for anonymity in the c.s.r reviewing process. You have the right to your beliefs. Just don't pretend that this has anything to do with journal publication. > |> Yes. I invite you---any of you---to explain what comp.sources.reviewed > |> would have done for my latest package, volume24/yabbawhap in c.s.unix. > |> Rich made no changes to it, so it's easy competition, right? Surely you > |> can point out *some* advantage in your precious ``reviewing'' process. > |> All I see is that c.s.reviewed would take weeks where Rich took days. [ ... ] > Therefore, to answer your question -- the c.s.r review process may have found > problems that you did not anticipate. The gamma testing process found lots of problems that I did not anticipate, but that happened *before* I published the sources. I again invite you to explain what you would have done with the package, exactly as it went out on comp.sources.unix. You're saying that you ``may have found problems''; I say you should come down out of the clouds and try to find problems. The package is right there! Make an example of it! Have a blast! [ in reference to some c.s.unix package ] > C.s.r would not, in my opinion, have allowed that mistake to > happen. Your guidelines give ``nlist'' as a prototypical package name, and you're saying the group is going to catch mistakes? ---Dan
rickert@mp.cs.niu.edu (Neil Rickert) (04/15/91)
In article <1991Apr14.030440.1814@rick.doc.ca> csr@calvin.doc.ca (Andrew Patrick as CSR Moderator) writes: >In article <16831:Apr1306:25:0591@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >>The reviewers are still arguing even the most basic issues: anonymity >>and publication of reviews. Sure, they need to work privately to iron I voted against comp.sources.reviewed . But the group was approved anyway. Now I am willing to sit back and wait to give the group a chance to prove itself. Why can't we all do that, and stop this silly bickering over the net. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
scs@iti.org (Steve Simmons) (04/15/91)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <nolan.671566523@helios> nolan@helios.unl.edu writes: >> Incidentally, that first post called for the creation of a reviewing >> process like that used for professional journals, so the insistence of >> anonymity for those reviewers who desire it should not come as much of >> a shock. >The shock is that you would have even considered the opposite. It is >exceedingly rare for a referee to give his name. Ever. When I edited the LISA proceedings, I (as `moderator') collected the referees comments, filed off the identifying marks, and passed them on to the authors. In several cases the reviewer volunteered to be identified to the author or asked to contact the author directly. In several cases the author asked for clarification on a comment and the reviewer then made direct contact with the author. So I would disagree with "exceedingly rare". Andrew did originally presume complete anonymity. I (among others) asked for permission to contact the author directly if circumstances seemed to warrant. -- "Our informal mission is to improve the love life of operators worldwide." Peter Behrendt, president of Exabyte. Quoted in Digital Review, Feb 4, 1991.
jmaynard@thesis1.med.uth.tmc.edu (Jay Maynard) (04/15/91)
In article <12409:Apr1513:14:4591@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >You have the right to your beliefs. Just don't pretend that this has >anything to do with journal publication. One more time: *WHAT* *DIFFERENCE* *DOES* *IT* *MAKE*??! The guidelines as discussed here match what the proposal (which you apparently didn't read beyond the point where it said that it was *MODELED* on journal publication) that was voted on said in all material points. Why can't you drop the subject until we get some actual examples of the process inaction? -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jmaynard@thesis1.med.uth.tmc.edu | adequately be explained by stupidity. "X.400 is the mail system of the future, and I hope it stays that way." -- Erik E. Fair
wirzenius@cc.helsinki.fi (Lars Wirzenius) (04/15/91)
In article <1991Apr14.232818.15851@athena.mit.edu>, jik@athena.mit.edu (Jonathan I. Kamens) writes: > In article <6787:Apr1420:38:3991@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > |> > There are currently two or > |> > three alternatives to comp.sources, c.s.r is just another option. > |> > |> That's one of its biggest problems. > > I've never understood this attitude. Why is giving people more options a > problem? Doesn't c.s.r accepts and review sources to non-Unix systems as well as for Unix systems? This alone is a good enough reason to give the group a try, IMHO (or do there exist moderated, reviewing source groups for most systems? I don't think I've seen any, but I'm often wrong anyway). -- Lars Wirzenius wirzenius@cc.helsinki.fi
peter@ficc.ferranti.com (Peter da Silva) (04/15/91)
The opportunity to get a bunch of extra final-beta testers, with a bunch of weird hardware, to test my program before it's published? Sounds like a great idea to me. Not one of us is getting tenure because of what we publish on the net (though perhaps some folks out there should: Henry, Larry, Dan, ...), so why force a strict conformity to a mechanism designed for a more highly competitive environment? -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
jik@athena.mit.edu (Jonathan I. Kamens) (04/15/91)
In article <12026:Apr1512:29:4191@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: |> Okay, I'm willing to believe that comp.sources.reviewed has the |> *potential* to provide (marginally) faster service than c.s.unix. Since |> this is its biggest (if not only) possible advantage, why don't you try |> to imitate a bit of what journals really do: put received, revised, and |> (if it matters) accepted dates on each article. Dan, do you deny the claim I have made that a patch I sent to Rich Salz, which he said he would post to comp.sources.unix, was still unposted eight months later? If you do not deny that, then do you deny the (implicit or explicit) claim I have made that comp.sources.reviewed will never take close to eight months to review a package or patch? If you do not deny that, then how can you say that the potential in comp.sources.reviewed is only to provide "marginally" faster service than comp.sources.unix. It seems logically obvious to me that if comp.sources.unix has taken as long as eight months in some cases to post simple submissions, and if it is likely that comp.sources.reviewed will never take that long, then the service provided by comp.sources.reviewed is significantly more than "marginally" faster than the service provided by comp.sources.reviewed. |> If you commit yourself now to showing what your real delays are, you'll |> be able to look back in a few months and show me that I was wrong---if |> you have anything published in a few months, that is. I think that putting received, revised (if relevant) and accepted dates on our postings, something which (as far as I know) no other source group moderator (including Rich Salz -- how can you make any claims at all about the speed of comp.sources.unix if Rich has never said publicly how long his lead time is?) has ever done, is an excellent idea. In case there are reviewers who do not read this newsgroup, I will forward it to the reviewers mailing list. Incidentally, Dan, I am willing to bet you any amount of money or any stake you name that we will have something published "in a few months." -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
jik@athena.mit.edu (Jonathan I. Kamens) (04/16/91)
In article <12178:Apr1512:46:5091@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: |> > Do you have some evidence to back up your claim that people are not getting |> > what they expected to get? If so, could you perhaps present it to us? |> |> Sure. Journals do A. The current guidelines say B. You're considering |> changing the guidelines to A. First of all, I don't understand what you mean here. You have said that we aren't really modelling things after a real journal (like you say we have claimed), but here you say that we are considering changing the guidelines to those of a real journal. Perhaps you meant, "You're considering changing the guidelines to C," or something like that? Second, as Andrew Patrick has pointed out other postings in this newsgroup, there is little evidence to back up your claim that we are changing the group as described in the charter. I will not rehash what he has said, since he said it well. Incidentally, it seems to me that if the many people who voted for the group thought we were changing it inappropriately, at least one of them would complain, don't you think? Instead, the only person complaining about alleged changes after the vote is someone who voted against the newsgroup in the first place. Interesting. Third, the realistic/fatalistic point of view. In the "real world" of the Usenet, a moderator can do pretty much whatever he wants once a group has been passed. As I have said at least twice in other postings, if people decide that the moderator has not met the goals of the group as described in the discussion and voting, they will not use the group, and it will wither and die. If, on the other hand, they find the group useful, it will flourish. As someone else has pointed out in another posting, now that the vote has happened and the newgroup message has been sent out, arguing about whether or not we are sticking to the charter is an excercise in futility. And if you think that things shouldn't be that way, then you should be arguing to change the way the Usenet works. And comp.sources.d isn't the place for that argument. |> There is absolutely no way that all the |> voters can be getting what they expected, unless they expected both A |> and B. I find it highly likely that some of the voters would be (e.g.) |> as shocked by the idea of publishing reviews as I was, if not more. Andrew Patrick has already pointed out that the question of publishing reviews was discussed in the charter and discussion period, and that there *are* journals which publish at least excerpts from reviews when papers are printed. |> Now it could be that people expected A, and you're going to end up with |> A, and B was just a big mistake. In that case I'm justified for flaming |> it, right? "Justified for flaming" is an oxymoron, IMHO. You can discuss how the group is going to turn out all you want. At this point, however, discussing the vote and whether or not we're sticking to the charter strikes me as a most useless endeavor. |> By the way, I didn't claim at first that people are not getting what |> they expected to get. I said that they *may* get something only loosely |> correlated with what they voted for. This is obviously true for any |> group that considers drastic changes after the vote. You seem to be the only person who believes that the people running the group are considering drastic changes after the vote. And you have presented little evidence to support this claim; I will begin to believe your claims about what was said and not said during the discussion period and in the charter when you start quoting from articles posted during the discussion period. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
jik@athena.mit.edu (Jonathan I. Kamens) (04/16/91)
In article <12409:Apr1513:14:4591@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: |> The gamma testing process found lots of problems that I did not |> anticipate, but that happened *before* I published the sources. First of all, your gamma testing process may not have found all of the problems. Second, the review process provided by c.s.r is, in my opinion, meant to be similar to the "gamma testing" process you mention. Many people don't have access to a lot of people on lots of different systems to ask them to test their software. They can send it to c.s.r and ask us to test and review it. If your gamma testing process was useful, and c.s.r provides a service to people which is similar to your gamma testing process, then it seems obvious to me that c.s.r is useful. |> I again invite you to explain what you would have done with the package, |> exactly as it went out on comp.sources.unix. You're saying that you |> ``may have found problems''; I say you should come down out of the |> clouds and try to find problems. The package is right there! Make an |> example of it! Have a blast! You persist in your belief that your one package, in your particular situation, can be used as a general proof of properties that would hold for all packages in all situations. I've already pointed out this gaping flaw in your argument once; you ignored me the first time. Are you going to ignore me again? |> [ in reference to some c.s.unix package ] |> > C.s.r would not, in my opinion, have allowed that mistake to |> > happen. |> |> Your guidelines give ``nlist'' as a prototypical package name, and |> you're saying the group is going to catch mistakes? Irrelevant and juvenile comments like these do not lend any credence to your point of view. I KNOW that the package I mentioned had mistakes that would have been caught by the c.s.r review process, because I KNOW that the package would not compile in many configurations as it was provided, and the first thing c.s.r reviewers would try to do would be to compile it. I also KNOW that they would have criticized the documentation for being sparse and vague, and asked the author to clean it up. I know all this because I would probably have been one of the reviewers for the package, and I would have done all of this. And I respect the other reviewers enough to believe that even if I had not been one of the reviewers, one of them would have caught the same mistakes that I did, especially since all I had to do to catch the mistakes was try to compile the program. You have made the generarl assertion that c.s.r cannot provide a useful service. As proof of your general assertion, you have offered a particular case for which it holds true. That is the first flaw in your logic. Despite the fact that it is unnecessary (in a strict debate sense) for me to refute your assertion since it is not logically valid, I did so by presenting a counter-example; one counter-example disproves a general assertion, as I am sure you are aware. Your attempt at refuting my counter-example consisted of the brilliant logical maneuver of making fun of the submission guidelines for the newsgroup. My admiration for your technique grows by leaps and bounds. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) (04/16/91)
In article <1991Apr15.131708.6168@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >Now I am willing to sit back and wait to give the group a chance to prove >itself. > > Why can't we all do that, and stop this silly bickering over the net. Because Dan Bernstein likes to hear himself talk. If more people used global kill files, we could reduce the bickering on usenet many-fold. But that's an unreachable dream.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/16/91)
In article <4967@lib.tmc.edu> jmaynard@thesis1.med.uth.tmc.edu (Jay Maynard) writes: > In article <12409:Apr1513:14:4591@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >You have the right to your beliefs. Just don't pretend that this has > >anything to do with journal publication. > One more time: > *WHAT* *DIFFERENCE* *DOES* *IT* *MAKE*??! Many people involved with refereed journals would find the aforementioned pretense to be exceedingly offensive. To put it simply, it's not true, and nobody should attempt to make a group succeed with false advertising. > Why can't you drop the subject until we get some actual examples of the process > inaction? Okay, I'll do so; I think I've made my points clear enough. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/16/91)
In article <1991Apr15.164926.6468@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > If you do not deny that, then how can you say that the potential in > comp.sources.reviewed is only to provide "marginally" faster service than > comp.sources.unix. Tsk. You seem to be arguing that since you had a posting delayed, everyone must have had postings delayed, and so anything faster than eight months is a huge improvement. I just don't think comp.sources.unix is so slow, and I invite you to survey other people who have actually posted to the group rather than continuing to chat with me about our theories. Until you do that, truce? > then > the service provided by comp.sources.reviewed is significantly more than > "marginally" faster than the service provided by comp.sources.reviewed. Ahem. :-) ---Dan
src@scuzzy.in-berlin.de (Heiko Blume) (04/16/91)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <1991Apr14.232818.15851@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: >> I see nothing wrong with reviewers contacting the submitter of a package. >It's not *wrong*, just extremely unusual. The guidelines say ``Reviewers >may contact you for information and clarification''; the default in >journal publication is that referees ask the editor to forward comments >and questions. excuse me, but who the **** cares what's usual in the paper based publication business? we're on a NET and that's just what makes it possible to be faster, more flexible, more individual etc. do you think i'd send paper mail to a submitter, or send it to the moderator to forward it (which all adds waiting time) when i can send him email directly, so i can get a answer REAL fast, like in some hours or so? we're not into academic stuff here or whatever, but into SOURCES were the typical mail will be "core dumped here and there" or "what the hell does that function do?". you know, first you complain that it will take very long for sources to appear in c.s.r and then you say that overhead is usual. somewhat contradictory, eh? also, i'm not posting anonymously here. fine. what does that tell you? nothing. i live 10000 miles away, and i can change my /etc/passwd as i please. the same is probably correct for many of the reviewers. we want to review sources. we do not testimony in the watergate affair. >I'm glad you think you know what you're doing. Apparently that has very >little to do with the guidelines. I suggest you hire a writer. do you know what a "Paragraphenreiter" is? -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 [voice!] public UNIX source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
src@scuzzy.in-berlin.de (Heiko Blume) (04/16/91)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >> |> Yes. I invite you---any of you---to explain what comp.sources.reviewed >> |> would have done for my latest package, volume24/yabbawhap in c.s.unix. i would have told you that it lacks basic error checking. try it on a full filesystem some time. -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 [voice!] public UNIX source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/17/91)
In article <1991Apr16.131650.24389@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes: > brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >> |> Yes. I invite you---any of you---to explain what comp.sources.reviewed > >> |> would have done for my latest package, volume24/yabbawhap in c.s.unix. > i would have told you that it lacks basic error checking. > try it on a full filesystem some time. Okay, I just did; it quit with ``yabba: fatal: output error'' when the filesystem filled up. I assume putchar() returned EOF, and since the code tests for EOF throughout, there's no way an output error could have slipped through. What's the problem? Perhaps you accidentally tested compress instead of yabba; compress does not test for I/O errors. Or did you see some problem in the code? It's true that ``output error'' isn't too helpful, but I didn't want to sacrifice portability just to get UNIX error messages. I welcome suggestions for how to solve this. If you ever do find a bug in my code, by the way, you should post it to comp.sources.bugs as well as sending it to me. Thanks. I hope, by the way, that reviews in comp.sources.reviewed are slightly more useful, informative, or at least comprehensive than the above report. I would recommend that in future reports you list your system architecture and OS, as well as compile options, and explain the circumstances under which you saw whatever behavior you say you saw. You might start by looking at FORMLETTER in the yabbawhap package---out of the hundred or so reports I've received on yabbawhap, more than ninety used FORMLETTER to reply. (Yeah, I was surprised by this too.) ---Dan
kolb@kub.nl (Hans-Peter Kolb) (04/17/91)
In article <12422:Apr1602:14:1191@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: Dan> Tsk. You seem to be arguing that since you had a posting delayed, Dan> everyone must have had postings delayed, and so anything faster than Dan> eight months is a huge improvement. I just don't think Dan> comp.sources.unix is so slow, and I invite you to survey other people Dan> who have actually posted to the group rather than continuing to chat Dan> with me about our theories. Until you do that, truce? Not that it matters much, but the following just appeared in comp.sources.bugs (article <1991Apr16.031008.6923@ux1.cso.uiuc.edu> by egray@osiris.cso.uiuc.edu (Emmet P. Gray): |> This is patch #4 to the Mtools v2.0 distribution package. (...) |> |> Mtools was posted to the unix-pc.sources news group (and mailed to Rich |> Salz, the moderator of comp.sources.unix) on the 17th of September 1990. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |> Since then, patches 1-3 have been posted to unix-pc.sources, |> comp.sources.bugs, and emailed to Rich Salz. Dan> Ahem. :-) Me, too. ------------------------------------------------------------------------ hans-peter kolb kolb@kub.nl Computational Linguistics kolb@htikub5.bitnet Tilburg University (KUB) P.O.Box 90 153 The Netherlands NL-5000 LE Tilburg ------------------------------------------------------------------------
peter@ficc.ferranti.com (Peter da Silva) (04/18/91)
In article <1307:Apr1702:20:0991@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > but I didn't want to sacrifice portability just to get UNIX error > messages. I welcome suggestions for how to solve this. How does calling "perror" sacrifice portability? Any compiler that doesn't include a functioning perror() in their standard I/O library isn't worth supporting... it's probably got other major limitations even if it satisfies the letter of the ANSI C standard. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/19/91)
In article <FUSA56C@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > In article <1307:Apr1702:20:0991@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > > but I didn't want to sacrifice portability just to get UNIX error > > messages. I welcome suggestions for how to solve this. > How does calling "perror" sacrifice portability? Any compiler that doesn't > include a functioning perror() in their standard I/O library isn't worth > supporting... it's probably got other major limitations even if it satisfies > the letter of the ANSI C standard. While I'd love to pretend that most compilers ``out there'' are ANSI C (and UNIX and a VAX and...), I don't want to keep my code from working on the vast majority of implementations. I was under the impression that some environments either do not provide perror() or do not set errors in stdio; if perror() is universally available, I'll gladly recode the error messages around sprintf() and perror(). ---Dan
peter@ficc.ferranti.com (Peter da Silva) (04/19/91)
In article <25835:Apr1908:41:2991@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > While I'd love to pretend that most compilers ``out there'' are ANSI C > (and UNIX and a VAX and...), I don't want to keep my code from working > on the vast majority of implementations. I was under the impression that > some environments either do not provide perror() or do not set errors in > stdio; if perror() is universally available, I'll gladly recode the > error messages around sprintf() and perror(). errmsg(object, context) char *object; char *context; { extern perror(); char buffer[256]; /* or however big you want it */ extern char *progname; sprintf(buffer, "%s: ", progname); sprintf(buffer+strlen(buffer), context, object); perror(buffer); } #ifdef NO_BUILT_IN_PERROR perror(s) { fprintf(stderr, "%s\n", s) } #endif /* example: if(!fp) errmsg(filename, "Can't open %s for reading"); */ -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
meissner@osf.org (Michael Meissner) (04/21/91)
In article <B9UA6DD@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: | In article <25835:Apr1908:41:2991@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: | > While I'd love to pretend that most compilers ``out there'' are ANSI C | > (and UNIX and a VAX and...), I don't want to keep my code from working | > on the vast majority of implementations. I was under the impression that | > some environments either do not provide perror() or do not set errors in | > stdio; if perror() is universally available, I'll gladly recode the | > error messages around sprintf() and perror(). Perror has been in Unix since V7. Strerror on the other hand is a creation of the ANSI committee. | errmsg(object, context) | char *object; | char *context; | { | extern perror(); | char buffer[256]; /* or however big you want it */ | extern char *progname; | | sprintf(buffer, "%s: ", progname); | sprintf(buffer+strlen(buffer), context, object); | perror(buffer); | } This can produce the wrong error message if sprintf sets errno (for example if it calls malloc and malloc fails). -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?
peter@ficc.ferranti.com (Peter da Silva) (04/23/91)
In article <MEISSNER.91Apr20151434@curley.osf.org> meissner@osf.org (Michael Meissner) writes: > This can produce the wrong error message if sprintf sets errno (for > example if it calls malloc and malloc fails). I'm sure it can, but there are more systems where errno doesn't exist and perror still works than where sprintf calls malloc. As you say, if you can depend on ANSI C you can use strerror. If not, I'd rather stick to the lowest common denominator. In fact, I don't know of any implementations where sprintf can set errno. Does *anyone* know of one? (I once considered, on the Amiga, having perror pop up a requestor if the program was called from Workbench...) -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
kentfo@polari.UUCP (Kent Forschmiedt) (04/23/91)
In article <MEISSNER.91Apr20151434@curley.osf.org> meissner@osf.org (Michael Meissner) writes: > This can produce the wrong error message if sprintf sets errno (for > example if it calls malloc and malloc fails). In article <6_WAABB@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > >I don't know of any implementations where sprintf can set errno. >Does *anyone* know of one? Who cares? If there is one, or somebody someday makes one, somebody will eventually be bitten. Many years ago, I began adding two lines of code to my versions of these functions, and stopped losing sleep. errorthing(char *whatever) { char buf[200]; int etmp = errno; /* whatever */ errno = etmp; perror(buf); } -- Kent Forschmiedt ... kentfo@polari ... uw-beaver!sumax!polari!kentfo