davidl@teklds.UUCP (David Levine) (11/23/85)
I've thought of a way we could reduce the traffic in net.sources.mac enough to
placate the cash-strapped backbones into keeping it going. This method would
not require moderation (although moderation might help), would not eliminate
the posting of binaries, and would reduce flames about shareware.
One simple rule: POST NOTHING NOT WRITTEN OR MODIFIED BY YOURSELF.
This rule would allow the posting of binaries, so those of us with no compiler
(or who don't have that particular compiler) could still use them. It would
also tend to increase the amount of source posted, since almost all of the
non-source postings have been of programs snagged off of CompuServe, and many
people on Usenet who write their own programs want to show off their nifty
algorithms.
This rule would discourage the posting of programs readily available from other
sources (e.g. user's groups) and make the net into a unique resource. It would
encourage the sharing of "neat hacks" and increase programming participation.
It would also lead to the evolution of code (as the code mutates in the hands
of hundreds of programmers and only the bug-free versions survive to
reproduce). Also, if the author of every posting is on the net, everyone on
the net can contact the author with bugs (and fixes!)
Bad points: No enforcement is possible, and if the rule is not enforced it's
likely to be violated, leading to exactly the situation we have now. Posting
of source rapidly leads to multiple versions, many buggy and all kludges-on-
kludges.
What do you think? I'd like to see discussion in net.micro.mac only, since
net.news.group is a hotbed of flamage and the issues involved here are in large
part technical Macintosh issues.
David D. Levine (...decvax!tektronix!teklds!davidl) [UUCP]
(teklds!davidl.tektronix@Udel-Relay) [ARPA] (experimental)gus@Shasta.ARPA (11/25/85)
> One simple rule: POST NOTHING NOT WRITTEN OR MODIFIED BY YOURSELF.
This certainly does not work because not everyone has access to every net
and/or user group. Cross postings SHOULD be encouraged as long as each
person knows what is already on that particular net/archive. I agree that
posting N copies of something by N people around the country is wasteful,
but this, in general, has not been a major problem on net.sources.mac.
Often user groups GET their programs from the net. I know first hand because
I am on the committy that creates disks for the Stanford Mac User Group.
Cross-postings help us a lot.ln63fkn@sdcc7.UUCP (Paul van de Graaf) (11/25/85)
In article <1308@teklds.UUCP> davidl@teklds.UUCP (David Levine) writes: >I've thought of a way we could reduce the traffic in net.sources.mac enough to >placate the cash-strapped backbones into keeping it going. > >One simple rule: POST NOTHING NOT WRITTEN OR MODIFIED BY YOURSELF. > >This rule would allow the posting of binaries, so those of us with no compiler >(or who don't have that particular compiler) could still use them. [ Sorry for the cross-post to net.news.group, David, but this isn't a flame. ] A fine idea, but I think it inherently requires net.sources.mac change to mod.sources.mac. Net.sources.mac supporters: Can you give an argument to keep your newsgroup unmoderated? The only ones I've ever heard are: [ whining mode ] "It's too much trouble to post to moderated groups." [ sensible mode ] "Moderation introduces a lag into the posting process." [ silly blather mode ] "Moderation is censorship. Censorship is a bad thing. Ergo, moderation is bad." I think none of these arguments hold water when applied to a group which posts sources/binaries. If you have other objections to moderation, I'd like to hear them. By mail if you please. If you feel you must post, keep it concise. Thank you. Paul van de Graaf sdcsvax!sdcc7!ln63fkn U. C. San Diego
planting@uwvax.UUCP (W. Harry Plantinga) (11/25/85)
> One simple rule: POST NOTHING NOT WRITTEN OR MODIFIED BY YOURSELF. > This would also eliminate things like binhex, switcher, REdit, ResEdit, freeterm, diskutil, fedit, packit, DAMover, font/da mover, memtest, disktest, alert/dialog editor, font editor, icon editor, and so on. Some of these seem to be useful programs! Harry Plantinga planting@colby.wisc.edu {ihnp4,allegra,heurikon,seismo}!uwvax!planting
mazlack@ernie.BERKELEY.EDU (Lawrence J. &) (11/26/85)
> >What do you think? I'd like to see discussion in net.micro.mac only, since >net.news.group is a hotbed of flamage and the issues involved here are in large >part technical Macintosh issues. > Who among us reads net.news.group anyhow. ...Larry Mazlack
gus@Shasta.ARPA (11/27/85)
> > [ whining mode ] "It's too much trouble to post to moderated groups." > [ sensible mode ] "Moderation introduces a lag into the posting process." > [ silly blather mode ] "Moderation is censorship. Censorship is a bad thing. > Ergo, moderation is bad." > My main objection to moderation is that it creates a bottleneck; either mechanical or human. Everything done here is volunteer, so if the moderator is snowed under with work, he may slack off for a few days on forwarding postings. Such is the current case with INFO-MAC. Formerly, a new digest would come out fairly regularly every few days. More recently, there have been large gaps between postings, and those postings have been relatively huge. Even if the final volume is the same, it is simply better if the flow of information is not hindered in any way.
rec@mplvax.UUCP (Richard Currier) (11/27/85)
In article <11089@ucbvax.BERKELEY.EDU> mazlack@ernie.UUCP (Lawrence J. Mazlack) writes: >> >>What do you think? I'd like to see discussion in net.micro.mac only, since >>net.news.group is a hotbed of flamage and the issues involved here are in large >>part technical Macintosh issues. >> > >Who among us reads net.news.group anyhow. > ...Larry Mazlack If you don't take an interest in what is being said in net.news.group you are not going to be aware of what the backbone site system administrators are thinking. If you don't make your ideas known to them you are certainly going to lose the Mac groups. They may be history already due to the nature of the net itself. -- richard currier marine physical lab u.c. san diego {ihnp4|decvax|akgua|dcdwest|ucbvax} !sdcsvax!mplvax!rec