RFD: comp.std.csharp
Nigel Perry
unmoderated group comp.std.csharp
This is a formal Request For Discussion (RFD) for the creation of
the worldwide unmoderated newsgroup comp.std.csharp. This is not
a Call for Votes (CFV); you cannot vote at this time. Procedural
details are below.
Newsgroup line:
comp.std.csharp Discussions on the ECMA/ISO Common Language.
RATIONALE: comp.std.csharp
There are no newsgroups to discuss the ECMA/ISO Standards for C#.
There are multiple implementations of this standard; including the
Microsoft product, Mono, Rotor and DotGNU; and a forum for the
discussion of the Standard and possible future directions would be of
benefit to the community. The ECMA Technical Groups for C# and CLI
are proposing this newsgroup and will monitor the postings.
CHARTER: comp.std.csharp
The purpose of this newsgroup shall be to establish and maintain a
forum for the open discussion of issues related to the ECMA/ISO C#
Standard. Topics may include but are not limted to matters such as the
following:
- Meaning of the Standard
- Implementation of the Standard
- Possible errors/omissions in the Standard
- Possible future directions of the Standard
ECMA and ISO have formal procedures for input to, and reporting errors in,
Standards. This group will in no way replace those procedures. The group
is intended as a forum for the community. However the ECMA Technical
Group for the Standard will monitor and take note of discussions on the
newsgroup.
END CHARTER.
PROCEDURE:
This is a request for discussion, not a call for votes. In this phase
of the process, any potential problems with the proposed newsgroups
should be raised and resolved. The discussion period will continue
for a minimum of 21 days (starting from when the first RFD for this
proposal is posted to news.announce.newgroups), after which a Call For
Votes (CFV) will be posted by a neutral vote taker. Please do not
attempt to vote until this happens.
All discussion of this proposal should be posted to news.groups.
This RFD attempts to comply fully with the Usenet newsgroup creation
guidelines outlined in "How to Create a New Usenet Newsgroup" and "How
to Format and Submit a New Group Proposal". Please refer to these
documents (available in news.announce.newgroups) if you have any
questions about the process.
DISTRIBUTION:
This RFD has been posted to the following newsgroups:
news.announce.newgroups
news.groups
and the following mailing lists:
<dotnet...@di.unipi.it>
Subcribe via: dotnet-ssc...@di.unipi.it
<dotnet...@discuss.develop.com>
<dotn...@discuss.develop.com>
<dotne...@discuss.develop.com>
Proponent: Nigel Perry <ni...@cosc.canterbury.ac.nz>
(on behalf of ECMA TC39 TG2&3)
Proponent: Rex Jaeschke <r...@rexjaeschke.com>
(on behalf of ECMA TC39 TG2&3)
Mean Green Dancing Machine
Nigel Perry <ni...@cosc.canterbury.ac.nz> wrote:
>
> REQUEST FOR DISCUSSION (RFD)
> unmoderated group comp.std.csharp
Without reading this proposal, my first reaction is that you should
probably consider starting with comp.lang.csharp before trying for
comp.std.csharp. Can you give us an estimate for *current* traffic
about C# on Usenet (both including and excluding the microsoft.* groups)?
What makes you think the mailing list traffic will move to Usenet?
--
--- Aahz <*> (Copyright 2003 by aa...@pobox.com)
Hugs and backrubs -- I break Rule 6 http://rule6.info/
Androgynous poly kinky vanilla queer het Pythonista
blog blog blog GINGER blog blog blog GINGER
Eric Gunnerson
making sure you leave news.groups on the newsgroups line.
"Nigel Perry" <ni...@cosc.canterbury.ac.nz> wrote in message
news:10576239...@isc.org...
Jon Skeet
> >
> > REQUEST FOR DISCUSSION (RFD)
> > unmoderated group comp.std.csharp
>
> Without reading this proposal, my first reaction is that you should
> probably consider starting with comp.lang.csharp before trying for
> comp.std.csharp.
I would have thoroughly endorsed that - if it had happened a year and a
half ago. As it is, the microsoft.public.dotnet.languages.csharp group
gets a *lot* of traffic (admittedly much of it on general-.NET-stuff-
done-in-C# rather than C# language specifics) and I don't think people
would be likely to switch to a comp.* group from that, unfortunately. I
could be wrong, of course.
I don't think the proposal is going for the same kind of traffic though
- as I read it, it's going more for "language lawyer" traffic.
> Can you give us an estimate for *current* traffic
> about C# on Usenet (both including and excluding the microsoft.* groups)?
I believe groups.google.com to be inaccurate when it claims ~28,600
threads for June, but its estimate of 1,400 for the first week of July
is more believable. (That's threads, not posts.)
As I said before though, I suspect (and indeed hope) that most of those
threads would *not* have ended up on the comp.std.csharp group. Indeed,
perhaps one reason to start a comp.lang.csharp group would be to give
somewhere in the comp.* groups for such posts to keep the comp.std
group more on-topic.
> What makes you think the mailing list traffic will move to Usenet?
I can only give myself as an example - I'm subscribed to a couple of
mailing lists about C# and the CLR because I was pointed to them as
"the places where the standards are discussed". If there'd been a
newsgroup available, I'd have jumped on that like a shot :)
--
Jon Skeet - <sk...@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too
Zane Thomas [.NET/C# MVP]
Nicholas Paldino [.NET/C# MVP]
I think I would like to see that. =)
--
- Nicholas Paldino [.NET/C# MVP]
- nicholas...@exisconsulting.com
"Eric Gunnerson" <ericgu...@microsoft.nospam.com> wrote in message
news:3f0b07b4$1...@news.microsoft.com...
Mikael Jansson
"Eric Gunnerson" <ericgu...@microsoft.nospam.com> wrote in message
news:3f0b07b4$1...@news.microsoft.com...
Jon Skeet
> If you would like to see this group created, please reply to this post,
> making sure you leave news.groups on the newsgroups line.
<snip>
Just to clarify (as we've already had one content-less post) - this is
*not* the vote. Please don't reply to this thread *just* because you
want the group. The vote comes later (and isn't conducted on the group
itself).
This thread is for *discussion* of the proposal, not for head-counting.
Phanindra
process behind the standards for C#. Many thanks for the initiative.
/Phanindra Mankale
IEEE CSDP
Nigel Perry <ni...@cosc.canterbury.ac.nz> wrote in message news:<10576239...@isc.org>...
Thomas Plum
Zane Thomas [.NET/C# MVP]
>Just to clarify (as we've already had one content-less post) - this is
>*not* the vote.
That was far from clear!
Jon Skeet
> On Tue, 8 Jul 2003 19:32:37 +0100, Jon Skeet <sk...@pobox.com> wrote:
>
> >Just to clarify (as we've already had one content-less post) - this is
> >*not* the vote.
>
> That was far from clear!
It was clear in the original RFD post (see quote below). Unfortunately
it wasn't clear from Eric's post.
<quote>
This is a request for discussion, not a call for votes. In this phase
of the process, any potential problems with the proposed newsgroups
should be raised and resolved. The discussion period will continue
for a minimum of 21 days (starting from when the first RFD for this
proposal is posted to news.announce.newgroups), after which a Call For
Votes (CFV) will be posted by a neutral vote taker. Please do not
attempt to vote until this happens.
</quote>
ba...@dmcom.net
>
> On Tue, 8 Jul 2003 19:32:37 +0100, Jon Skeet <sk...@pobox.com> wrote:
>
> >Just to clarify (as we've already had one content-less post) - this is
> >*not* the vote.
>
> That was far from clear!
>
This is a dusccusion period, designed to improve the proposal (if any
are needed). A post saying this is a good idea means little, a formal
vote is/might be held later (at the proponent(s) choosen). Discusion
about why you consider the proposed group can be useful as well.
During the RFD period discussion certainly can include campaigning to
gather votes, dabates can be useful and indirectly also improve the
proposed group's charter, justification, chances of passing its vote.
--
news:alt.pagan FAQ at http://www.dmcom.net/bard/altpag.txt
news:alt.religion.wicca FAQ at http://www.dmcom.net/bard/arwfaq2.txt
news:news.groups FAQ at http://www.dmcom.net/bard/ngfaq.txt
Want a new group FAQs http://web.presby.edu/~nnqadmin/nnq/ncreate.html
Penny Gaines
> If you would like to see this group created, please reply to this post,
> making sure you leave news.groups on the newsgroups line.
Please don't.
If you want to see this group created, follow the discussion on news.groups,
where appropriate post relevant messages of support (ensuring they are
crossposted to news.groups. Most importantly when you see the CFV (Call
For Votes) issued, follow the instructions in that so that your vote will
count.
[snip]
>> PROCEDURE:
>>
>> This is a request for discussion, not a call for votes. In this phase
>> of the process, any potential problems with the proposed newsgroups
>> should be raised and resolved. The discussion period will continue
>> for a minimum of 21 days (starting from when the first RFD for this
>> proposal is posted to news.announce.newgroups), after which a Call For
>> Votes (CFV) will be posted by a neutral vote taker. Please do not
>> attempt to vote until this happens.
[snip]
--
Penny Gaines
a decade on usenet
ru.ig...@usask.ca
I'm a news.groups regular. Like most of the regulars here, I usually
don't vote on proposals. However, I've got some comments and questions
for you (the proponent) which you might want to consider incorporating
your responses to in the next draft of your RFD ("2nd RFD:...").
In news.groups Nigel Perry <ni...@cosc.canterbury.ac.nz> wrote:
> REQUEST FOR DISCUSSION (RFD)
> unmoderated group comp.std.csharp
[snip]
>Newsgroup line:
>comp.std.csharp Discussions on the ECMA/ISO Common Language.
Ok, reading the RFD for comp.std.cli and then reading this below,
I have to wonder, isn't C# a subset of CLI, and if so, shouldn't the
name of this proposal be c.s.cli.csharp and thus be merged with the
c.s.cli propsal? OR alternatively, is C# a standard or an
implementation more along the lines of a language, and thus does
discussion belong in something like comp.lang.csharp?
This description line is vague. Which ECMA/ISO Common Language?
>RATIONALE: comp.std.csharp
>There are no newsgroups to discuss the ECMA/ISO Standards for C#.
My comments for cli also apply here. I just wish I remembered
what they were. I think there was stuff about: existing broader
topic groups that might contain discussions of C#; problems with
existing groups; enough readers; non-usenet forums and whether
their readers really want a usenet group; problems solved by
the proposed groups; problems created by the proposed group.
Basically, why do readers say they want the proposed group?
>There are multiple implementations of this standard; including the
>Microsoft product, Mono, Rotor and DotGNU; and a forum for the
change ";" to "-"
>discussion of the Standard and possible future directions would be of
>benefit to the community. The ECMA Technical Groups for C# and CLI
>are proposing this newsgroup and will monitor the postings.
I'm having a bit of difficulty separating this topic space and
CLI topics, at least to the extent that it is proposed as a peer
of c.s.cli rather than a subtopic of cli. You either need to
justify csharp being in the 3rd node, or move it down one level
and make it a cli subgroup.
>CHARTER: comp.std.csharp
My thoughts here are the same as with the comp.std.cli CHARTER.
>END CHARTER.
[snip]
>DISTRIBUTION:
>This RFD has been posted to the following newsgroups:
> news.announce.newgroups
> news.groups
My thought here are the same as the cli proposal, what about
other groups?
ru
--
My standard proposals rant:
Quality, usefulness, merit, or non-newsgroups popularity of a topic
is more or less irrelevant in creating a new Big-8 newsgroup.
Usenet popularity is the primary consideration.
Russ Allbery
> Ok, reading the RFD for comp.std.cli and then reading this below, I have
> to wonder, isn't C# a subset of CLI,
No, it's a programming language that's built on top of CLI (but wouldn't
necessarily have to be).
> and if so, shouldn't the name of this proposal be c.s.cli.csharp and
> thus be merged with the c.s.cli propsal?
That would be like making comp.std.cli.c or comp.std.cli.c++. It may make
some sense in some circumstances, but I don't think it's the most obvious
choice.
> OR alternatively, is C# a standard or an implementation more along the
> lines of a language, and thus does discussion belong in something like
> comp.lang.csharp?
Discussion of the langauge would belong in comp.lang.csharp, definitely.
But discussion of the language standardization would go in
comp.std.csharp. (See comp.lang.c vs. comp.std.c.)
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Zane Thomas [.NET/C# MVP]
>Had you actually read the entire RFD it would have been as clear as crystal.
No doubt - what I read was the "please reply" bit. If it has "please reply if
you have something to say" then I might not have replied.
Nigel Perry
> Mean Green Dancing Machine <aa...@pobox.com> wrote:
> > >
> > > REQUEST FOR DISCUSSION (RFD)
> > > unmoderated group comp.std.csharp
> >
> > Without reading this proposal, my first reaction is that you should
> > probably consider starting with comp.lang.csharp before trying for
> > comp.std.csharp.
>
> I would have thoroughly endorsed that - if it had happened a year and a
> half ago. As it is, the microsoft.public.dotnet.languages.csharp group
> gets a *lot* of traffic (admittedly much of it on general-.NET-stuff-
> done-in-C# rather than C# language specifics) and I don't think people
> would be likely to switch to a comp.* group from that, unfortunately. I
> could be wrong, of course.
>
> I don't think the proposal is going for the same kind of traffic though
> - as I read it, it's going more for "language lawyer" traffic.
Yes that is the general intention - a place for people to discuss the
details of the Standard. The Standards work is ongoing and members of
the ECMA/ISO committee would frequent the group if it is established.
It is not intended for questions like "how do I do X Y Z in C#?",
there are mailing lists already for such things.
Joel Marcey
thread]
Hello,
Possible minor changes to the RFD notwithstanding, I believe the content of
this RFD is *valid* and the creation of such a group would be *quite
beneficial*. In short, such a group could help ensure a more quality
standard, and a quality standard is a large key to acceptance and widespread
use.
Now, I agree that the group will probably not break any traffic records. But
I don't think that is the overall goal for the creation of this group.
Currently, any broadly public discussion of the standard occurs on public
mailing lists (the most popular being the DevelopMentor DOTNET-CX list).
However, the discussions on these lists are primarily focused upon actual
implementations of the standard (and consists of many how-to type questions,
etc). There is also quite a bit of noise as well. And while some efforts are
made by many in the ECMA task group responsible for the creation and
updating of the standard to monitor these lists, it can become quite
cumbersome to filter through the information to pick out legitimate
standards related inquiries.
The ECMA task group understands that the standard is not perfect. And while
the best and formal way to make provide input is to join ECMA and engage
within the task group, the task group understands this is not always
feasible. This group would serve as a public forum for comments re: the
standard, where the task group will monitor these comments and may even
discuss some relevant ones within the task group. This group will also serve
as a forum for input into possible future directions in the standard as
well. Of course, the task group cannot guarantee all or even any comments
will be discussed/incorporated into the standard (there is a formal process
for that), but the task group does have the intention to monitor this group
and act accordingly.
On the topic of "why isn't another mailing list dedicated to the standard
just created", my response to that is that, in my mind, mailing lists are
usually controlled by a specific entity (e.g. DevelopMentor) while usenet is
a more general, "public domain" type of discussion area.
The reason why this should be put under the heading of comp.std.csharp is
that
it should be made clear that this a group focused on the C# standard and
its content, and not on specific implementations.
This seems to be a very legitimate request for a discussion group on a very
legitimate topic and technology. I am all for it.
Regards,
- Joel
* The views expressed here do not necessarily reflect those of Intel
Corporation, its subsidiaries, or its employees
Jim Riley
Perry) wrote:
>It is not intended for questions like "how do I do X Y Z in C#?",
>there are mailing lists already for such things.
How do you intend to keep such discussion out of an unomoderated
newsgroup, especially since there is no other Big 8 group devoted to
C#?
--
Jim Riley
Jim Riley
wrote:
>ru igarashi <ru.ig...@usask.ca> writes:
>> OR alternatively, is C# a standard or an implementation more along the
>> lines of a language, and thus does discussion belong in something like
>> comp.lang.csharp?
>
>Discussion of the langauge would belong in comp.lang.csharp, definitely.
>But discussion of the language standardization would go in
>comp.std.csharp. (See comp.lang.c vs. comp.std.c.)
As an unmoderated group, comp.std.c, tends to end up being an
alternative to the comp.lang.c for discussing standard-compliant use
of the language rather than standardization per se. And in that case,
the group was deliberately set up to differentiate it from an existing
comp.lang.c. In the absence of an obvious choice it will be seen as
the place for discussing all aspects of the language.
It is quite ordinary for language standards to be discussed in
comp.lang.fortran, so why couldn't standardization of c# be discussed
in comp.lang.c-sharp? If there were need for a subgroup focused on
the standardization process, it could be added. Having the groups
side-by-side would be more likely to have the difference between the
groups immediately understood.
--
Jim Riley
Russ Allbery
> As an unmoderated group, comp.std.c, tends to end up being an
> alternative to the comp.lang.c for discussing standard-compliant use of
> the language rather than standardization per se.
I'm not sure that I see the distinction between those two topics.
> And in that case, the group was deliberately set up to differentiate it
> from an existing comp.lang.c. In the absence of an obvious choice it
> will be seen as the place for discussing all aspects of the language.
If it gets too much regular language use discussion, that would be an
excellent justification for creating a new comp.lang.* group, yes?
> It is quite ordinary for language standards to be discussed in
> comp.lang.fortran, so why couldn't standardization of c# be discussed in
> comp.lang.c-sharp?
It could be, if that's what the proponents want to do. But if there are
already other existing fora for discussion of the language, it may make
more sense to just create a group for the specific topic that isn't
currently well-served and then see where things go from there.
> If there were need for a subgroup focused on the standardization
> process, it could be added.
Likewise, if there were a need for a separate group on discussion of the
language itself, that too can be added later. I don't understand why
people think comp.std.* is magical.
Jon Skeet
Directing people to the MS group would probably be a good start. It's
widely available on general servers (I believe) and the MS news-server
is freely accessible.
Crimefighter
comp.lang
"Jon Skeet" <sk...@pobox.com> wrote in message
news:MPG.1976a1bfa...@dnews.peramon.com...
Mean Green Dancing Machine
Russ Allbery <r...@stanford.edu> wrote:
>Jim Riley <jim...@pipeline.com> writes:
>>
>> If there were need for a subgroup focused on the standardization
>> process, it could be added.
>
>Likewise, if there were a need for a separate group on discussion of the
>language itself, that too can be added later. I don't understand why
>people think comp.std.* is magical.
The problem is that I don't consider microsoft.* part of the public
Usenet system. IIRC, posts from outside Microsoft's news server don't
get gatewayed back.
It's not that I consider comp.std.* magical, but I consider it
sufficiently specialized that I'm concerned about traffic given that
there isn't existing Usenet traffic on this subject. We've had many
discussions in the past about the fact that moving mailing list traffic
to netnews doesn't work particularly well.
ru.ig...@usask.ca
>Russ Allbery <r...@stanford.edu> wrote:
>>Jim Riley <jim...@pipeline.com> writes:
>>>
>>> If there were need for a subgroup focused on the standardization
>>> process, it could be added.
>>
>>Likewise, if there were a need for a separate group on discussion of the
>>language itself, that too can be added later. I don't understand why
>>people think comp.std.* is magical.
>The problem is that I don't consider microsoft.* part of the public
>Usenet system. IIRC, posts from outside Microsoft's news server don't
>get gatewayed back.
>It's not that I consider comp.std.* magical, but I consider it
>sufficiently specialized that I'm concerned about traffic given that
>there isn't existing Usenet traffic on this subject. We've had many
>discussions in the past about the fact that moving mailing list traffic
>to netnews doesn't work particularly well.
Surely there is SOME discussion, perhaps in the server or
database groups?
Would it hurt to start the std group first, even if the greater
potential is for the bulk of the traffic being implementation
oriented? And if that turns out to be a problem, create the
lang group after? Clearly, the proponents are more interested
in the standards discussions rather than a lang group, so I
don't feel like pushing them towards a solely lang solution.
Most of their info is based on their field of interest, the
standards end. They may not have even considered the likelihood
of implementation discussion invading the proposed group,
that there may be tons of such discussions already taking
place, waiting for a more appropriate looking group. Ok,
suppose they are willing to accommodate some noise in the form
of non-standards discussion, there is still the way out of
creating another group later. Of course, if they totally
underestimate the volume of non-standards discussion, they
may end up with a dead group (as far as standards discussions
are concerned). What indicates to the proponents that
non-standards discussion won't move in, at least not in
significant quantity? Is that the concern here?
Unfortunately, we're having this conversation because the
proponents haven't supplied information of this sort in the RFD
(even if it's to say in the RATIONALE that implementation traffic
will be acceptable for a while). I do agree that the proponents
should consider the likelihood that non-standards discussions
will be drawn to the proposed group, that there's little they
will be able to do about it without creating an appropriate new
group afterward, and that proceeding as is may ultimately result
in a dead or unused group (for standards discussions). I wouldn't
mind seeing extra info on this in the next RFD draft.
The Ranger
[snip]
> Clearly, the proponents are more interested in the standards
> discussions rather than a lang group, so I don't feel like
> pushing them towards a solely lang solution.
> Most of their info is based on their field of interest, the
Doesn't this make the duration-of and interest-in this particular 'group
finite in an extreme sense then?
The Ranger
ru.ig...@usask.ca
You mean because the standard will at some point be locked down?
Not necessarily. What about extensions? :) What about new
"versions"? :p What about arguments about the stupidity of part
of the standard or of the standards committee? :b
Russ Allbery
> ru.ig...@usask.ca wrote:
>> Clearly, the proponents are more interested in the standards
>> discussions rather than a lang group, so I don't feel like pushing them
>> towards a solely lang solution. Most of their info is based on their
>> field of interest, the standards end. [snip]
> Doesn't this make the duration-of and interest-in this particular 'group
> finite in an extreme sense then?
Standardization is invariably a continuing process even after the first
one is published.
Brian Mailman
> The problem is that I don't consider microsoft.* part of the public
> Usenet system. IIRC, posts from outside Microsoft's news server don't
> get gatewayed back.
microsoft.public.* is... well... public. I read two of those groups and
post on occasion from Supernews.
B/
The Ranger
news:87adbnx...@windlord.stanford.edu...
> The Ranger <cuhula...@yahoo.com> writes:
> > ru.ig...@usask.ca wrote:
>
> >> Clearly, the proponents are more interested in the standards
> >> discussions rather than a lang group, so I don't feel like pushing
> >> them towards a solely lang solution. Most of their info is based
> >> on their field of interest, the standards end. [snip]
> >>
> > Doesn't this make the duration-of and interest-in this particular
> > 'group finite in an extreme sense then?
> >
> Standardization is invariably a continuing process even after the first
> one is published.
But... In my limited experience, most of the interest is in the first few
versions/revisions [anyway] where everyone is still trying to get their
particular points inserted into the forming standard, and committees are
attempting a unilateral consensus. Then, once the standard has been "fixed,"
the discussion turns towards implementations by particular vendors and
enforcement of the standard. But that doesn't change the defined limitedness
of such a 'group, would it?
The Ranger
The Ranger
news:beij0d$h6g$2...@tribune.usask.ca...
[snip]
> >> Clearly, the proponents are more interested in the standards
> >> discussions rather than a lang group, so I don't feel like
> >> pushing them towards a solely lang solution.
> >> Most of their info is based on their field of interest, the
> >> standards end. [snip]
> >>
> >Doesn't this make the duration-of and interest-in this particular
> >'group finite in an extreme sense then?
> >
> You mean because the standard will at some point be locked
> down? Not necessarily. What about extensions? :) What about
> new "versions"? :p What about arguments about the stupidity
> of part of the standard or of the standards committee? :b
"Lock down" isn't such a good term, in my limited experience... <G> A pole
is flagged and the committees then go about trying to work on a unilateral
consensus so that there won't be too many flavors floating around that
require ad hoc extensions, new versions, and errata. You'll still have to
have those new versions (customers just love them and the job security is so
there) but these come out slower, and a lot less frequently after the first
couple/three...
About The [On-going] Arguments: That's what a bunch of engineers and
managers gathered in a large conference room do best. But these, too,
quickly diminish over time.
The Ranger
Mean Green Dancing Machine
And do people reading those groups from the main Microsoft server ever
respond (or otherwise give indication of seeing non-Microsoft posts)?
Russ Allbery
> But... In my limited experience, most of the interest is in the first
> few versions/revisions [anyway] where everyone is still trying to get
> their particular points inserted into the forming standard, and
> committees are attempting a unilateral consensus. Then, once the
> standard has been "fixed," the discussion turns towards implementations
> by particular vendors and enforcement of the standard. But that doesn't
> change the defined limitedness of such a 'group, would it?
Which languages have you had experience with there? My experience doesn't
match yours (for Ada, C, C++, Java, and -- in passing -- Fortran); they
seem to have had a lot of interest in subsequent standards work well after
the first standard. Some of these are certainly discussed more on Usenet
than others, though.
Even if you're right, though, we're talking about a Usenet newsgroup with
a lifespan of at least five years, given the pace of issue of standards
and then corrections to the first standard. Seems fine to me.
Jon Skeet
> I think perhaps two groups should be created in concert....comp.std and
> comp.lang
Would there be significant traffic for comp.lang.csharp though? Why
would people post there rather than on the existing, well-used
microsoft.* newsgroup? If it had been set up much earlier, I'm sure it
would have taken off - but I suspect it's too late now.
Jon Skeet
> Usenet system. IIRC, posts from outside Microsoft's news server don't
> get gatewayed back.
Do you mean posts from outside MS's news server don't reach MS's news
server? I'm *pretty* sure that's not right, but I could test it if you
wish.
The thing is, while microsoft.* certainly isn't on *every* server, and
certainly isn't part of the Big-8, it *is* available to everyone for
free, and there's already a large reader base in the MS csharp
newsgroup.
> It's not that I consider comp.std.* magical, but I consider it
> sufficiently specialized that I'm concerned about traffic given that
> there isn't existing Usenet traffic on this subject. We've had many
> discussions in the past about the fact that moving mailing list traffic
> to netnews doesn't work particularly well.
The std newsgroup would meet a need which isn't met by the MS existing
groups. A lang newsgroup wouldn't have that property. I'm not sure
whether you're arguing against the std group or for a lang group though
:)
Jim Riley
wrote:
>Jim Riley <jim...@pipeline.com> writes:
>
>> As an unmoderated group, comp.std.c, tends to end up being an
>> alternative to the comp.lang.c for discussing standard-compliant use of
>> the language rather than standardization per se.
>
>I'm not sure that I see the distinction between those two topics.
"When I compiled my code with the -strictcompliance flag set, I got an
error message, what'd I do wrong?" is not really about
standardization.
>> And in that case, the group was deliberately set up to differentiate it
>> from an existing comp.lang.c. In the absence of an obvious choice it
>> will be seen as the place for discussing all aspects of the language.
>
>If it gets too much regular language use discussion, that would be an
>excellent justification for creating a new comp.lang.* group, yes?
And if they don't get enough votes to create that group? They're
stuck with the group as it is.
>> It is quite ordinary for language standards to be discussed in
>> comp.lang.fortran, so why couldn't standardization of c# be discussed in
>> comp.lang.c-sharp?
>
>It could be, if that's what the proponents want to do. But if there are
>already other existing fora for discussion of the language, it may make
>more sense to just create a group for the specific topic that isn't
>currently well-served and then see where things go from there.
It is unlikely that their proposal will result in the creation of a
group for the specific sub-topic that they are seeking a place to
discuss.
Do you think it odd that comp.unix.cray is more about Cray and less
about Unix, or do you think that is to be expected given that there is
not a comp.sys.cray?
>> If there were need for a subgroup focused on the standardization
>> process, it could be added.
>
>Likewise, if there were a need for a separate group on discussion of the
>language itself, that too can be added later. I don't understand why
>people think comp.std.* is magical.
If you mean that "std" will somehow magically ward off discussion of
the language, I don't think that it will. That is the basis of my
whole argument.
Standardization of c# is one aspect of the language, and would be best
served by containing all the discussion in a single group, or creating
adjacent subgroups so that the relationship is more obvious.
--
Jim Riley
Jim Riley
Machine) wrote:
>In article <3F0CD635...@sfo.com>,
>Brian Mailman <bmai...@sfo.invalid> wrote:
>>microsoft.public.* is... well... public. I read two of those groups and
>>post on occasion from Supernews.
>
>And do people reading those groups from the main Microsoft server ever
>respond (or otherwise give indication of seeing non-Microsoft posts)?
The last time I checked, maybe two years ago, messages were being
gated inward to the Microsoft server. In the case of some non-English
groups, this was a majority of the traffic.
--
Jim Riley
Jon Skeet
> respond (or otherwise give indication of seeing non-Microsoft posts)?
Yes. I've just made a test post from my company server, and it's shown
up on the MS server.
Mean Green Dancing Machine
Jon Skeet <sk...@pobox.com> wrote:
>Mean Green Dancing Machine <aa...@pobox.com> wrote:
>>
>> And do people reading those groups from the main Microsoft server ever
>> respond (or otherwise give indication of seeing non-Microsoft posts)?
>
>Yes. I've just made a test post from my company server, and it's shown
>up on the MS server.
Okie-doke, then my info is out of date.
TXSherry
[I snipped everyone who Mean Green was replying to. Hope it didn't
hurt, guys!!! mwahahaha.]
>The problem is that I don't consider microsoft.* part of the public
>Usenet system. IIRC, posts from outside Microsoft's news server don't
>get gatewayed back.
The one (two)* MS groups I frequent, infrequently <G>, I do so from
the german newserver, so I know that the MS groups do in fact interact
as normal on the servers. Whatever that means ;)
The main problem imo would be if servers carried comp.std.csharp (most
likely) and did not carry the microsoft heirarchy (possibility), how
then would you get the off topic csharp *language* traffic on those
non-MS carrying servers to move from the std group to the "proper"
group, when there IS NO proper group for them to go to.
Since csharp is a relatively new language and is taking off, there
might be usenet hungry csharpers who are waiting for a ng to jump
into. All this is conjecture though :) Except for the part about
them not having anywhere to go. I can see a conversation:
joenewbie: should it be void or int main?
bobstandards: move that discussion to the lang specific group
joenewbie: what group
bobstandards: THAT group --> over there
joewnewbie: I don't see any group like that! You can't make me go
away. this is unmoderated! should it be void or int main.
bobstandards: arg!
joenewbie: arg!!
<g>
*microsoft.public.inetserver.asp.general
*microsoft.public.inetserver.asp.db
Sherry
--
I have no email address any more except
@go.com. It's a cesspool of spam so I may
not see your message.
ck out: http://allmyfaqs.com/faq.pl?How_to_post
Richard H Miller
: The Ranger <cuhula...@yahoo.com> writes:
But based on what appears to be a total lack of any discussion on the topic
in the big-8 i am unconvinced that there is a need for two groups given the
existence of comp.std.misc. I would think that using this current group with
appropriate tagging should be the first step to demonstrate some interest
outside of a vendor-specific hierarchy
Brian Mailman
>
> In article <3F0CD635...@sfo.com>,
> Brian Mailman <bmai...@sfo.invalid> wrote:
> >Mean Green Dancing Machine wrote:
> >>
> >> The problem is that I don't consider microsoft.* part of the public
> >> Usenet system. IIRC, posts from outside Microsoft's news server don't
> >> get gatewayed back.
> >
> >microsoft.public.* is... well... public. I read two of those groups and
> >post on occasion from Supernews.
>
> And do people reading those groups from the main Microsoft server ever
> respond (or otherwise give indication of seeing non-Microsoft posts)?
Yup.
http://groups.google.com/groups?q=group:microsoft.public.*+author:bmailman%40sfo.invalid&hl=en&lr=&ie=UTF-8&selm=3EC668BA.E1CF8D14%40sfo.com&rnum=2
for an example.
B/
Jon Skeet
> The main problem imo would be if servers carried comp.std.csharp (most
> likely) and did not carry the microsoft heirarchy (possibility), how
> then would you get the off topic csharp *language* traffic on those
> non-MS carrying servers to move from the std group to the "proper"
> group, when there IS NO proper group for them to go to.
I would suggest that those posters connect to the MS news-server. It's
not like it costs money to do so or anything.
Russ Allbery
> Russ Allbery <r...@stanford.edu> wrote:
>> Jim Riley <jim...@pipeline.com> writes:
>>> As an unmoderated group, comp.std.c, tends to end up being an
>>> alternative to the comp.lang.c for discussing standard-compliant use
>>> of the language rather than standardization per se.
>> I'm not sure that I see the distinction between those two topics.
> "When I compiled my code with the -strictcompliance flag set, I got an
> error message, what'd I do wrong?" is not really about standardization.
It's about the standards and is a perfectly reasonable thing to discuss in
a comp.std.* group. It also directly informs the standardization process
not infrequently, since those sorts of discussions expose edge cases and
unclear areas in the standard.
>> If it gets too much regular language use discussion, that would be an
>> excellent justification for creating a new comp.lang.* group, yes?
> And if they don't get enough votes to create that group? They're stuck
> with the group as it is.
Then there wasn't too much regular language use discussion to actually
bother enough people to do something about it, was there?
> It is unlikely that their proposal will result in the creation of a
> group for the specific sub-topic that they are seeking a place to
> discuss.
I disagree. *shrug*
Russ Allbery
> But based on what appears to be a total lack of any discussion on the
> topic in the big-8 i am unconvinced that there is a need for two groups
> given the existence of comp.std.misc. I would think that using this
> current group with appropriate tagging should be the first step to
> demonstrate some interest outside of a vendor-specific hierarchy
These distinctions between newsgroup hierarchies look really arbitrary and
meaningless to anyone who isn't a news.groups regular, I think.
Richard H Miller
: Richard H Miller <ri...@bcm.tmc.edu> writes:
: > But based on what appears to be a total lack of any discussion on the
: > topic in the big-8 i am unconvinced that there is a need for two groups
: > given the existence of comp.std.misc. I would think that using this
: > current group with appropriate tagging should be the first step to
: > demonstrate some interest outside of a vendor-specific hierarchy
: These distinctions between newsgroup hierarchies look really arbitrary and
: meaningless to anyone who isn't a news.groups regular, I think.
Not in this case [and, I think, for many of the 'smaller' sites]. One of the differences
between USENET and other hierarchies is the somewhat more universal acceptance of these
newsgroups. We, for example, do not automatically accept [and rarely manually accept new
alt groups]. We do, however, accept most of the big-8 so I think it is not unreasonable to
see some evidence that there is traffic on the subject. Also, since a comp.std misc
group does exist and there is no evidence that either topic is being discussed in that
general group, I fail to see why we should create two new groups in that hierarchy.
Also, if such distinctions are arbritrary, why are the current microsoft groups not
sufficient.
Nigel Perry
> Would it hurt to start the std group first, even if the greater
> potential is for the bulk of the traffic being implementation
> oriented? And if that turns out to be a problem, create the
> lang group after? Clearly, the proponents are more interested
> in the standards discussions rather than a lang group, so I
> don't feel like pushing them towards a solely lang solution.
> Most of their info is based on their field of interest, the
> standards end. They may not have even considered the likelihood
> of implementation discussion invading the proposed group,
There is a lot of discussion on the C# language on a number of mailing
lists, and a number were copied with the RFD as listed at the end of
the RFD. What came to the attention of the Standards Committee was
that people wanted a forum to discuss the Standard and one which the
Committee would monitor. Hence this RFD.
It was considered whether the group might get swamped with
non-Standards posts, but it was felt (a) the mailing lists are there
and working and (b) if it became a problem then either a comp.lang or
moderation could be considered. However given the success of the
mailing lists it was felt this was unlikely to be a problem so an
unmoderated lang.std was proposed.
> that there may be tons of such discussions already taking
> place, waiting for a more appropriate looking group. Ok,
> suppose they are willing to accommodate some noise in the form
> of non-standards discussion, there is still the way out of
> creating another group later. Of course, if they totally
> underestimate the volume of non-standards discussion, they
> may end up with a dead group (as far as standards discussions
> are concerned). What indicates to the proponents that
> non-standards discussion won't move in, at least not in
> significant quantity? Is that the concern here?
The success of the other fora. We don't see it as a highly likely
problem.
Nigel
Russ Allbery
> There is a lot of discussion on the C# language on a number of mailing
> lists, and a number were copied with the RFD as listed at the end of the
> RFD. What came to the attention of the Standards Committee was that
> people wanted a forum to discuss the Standard and one which the
> Committee would monitor. Hence this RFD.
> It was considered whether the group might get swamped with non-Standards
> posts, but it was felt (a) the mailing lists are there and working and
> (b) if it became a problem then either a comp.lang or moderation could
> be considered. However given the success of the mailing lists it was
> felt this was unlikely to be a problem so an unmoderated lang.std was
> proposed.
One of the questions you should probably consider (and maybe address in
the rationale) is, if mailing lists are working well for the language
discussion, why a mailing list wouldn't also be a good choice for the
standards discussion. I think one of the things that's confusing people
is why the standards discussion will work better in a different medium
or at least a different hierarchy than the existing language discussion
and saying something about your thoughts in that area may assuage some of
those concerns.
Nigel Perry
> If you mean that "std" will somehow magically ward off discussion of
> the language, I don't think that it will. That is the basis of my
> whole argument.
There are a number of other succesful fora where questions on language
usage are asked and answered. Why would there really be a mass exodus
of people from a working Q&A forum to a new one for the Standard so
they can ask their "what's wrong with my for loop" question there?
Sure some language type questions will appear in a comp.std group, but
will it really be of problematic proportions? I expect not. This group
has been proposed in response to a request for a Standards forum from
people who haven't found such in the existing fora.
> Standardization of c# is one aspect of the language, and would be best
> served by containing all the discussion in a single group, or creating
> adjacent subgroups so that the relationship is more obvious.
Maybe a comp.lang would have been a good idea, and might yet be.
However the existing fora are up, running, and working well. Would
they migrate to a comp.lang?
Nigel
Mean Green Dancing Machine
Nigel Perry <ni...@cosc.canterbury.ac.nz> wrote:
>
>It was considered whether the group might get swamped with
>non-Standards posts, but it was felt (a) the mailing lists are there
>and working and (b) if it became a problem then either a comp.lang or
>moderation could be considered.
WARNING: moderation in place is currently prohibited
(Just in case you've been away from news.groups for a while.)
--
--- Aahz <*> (Copyright 2003 by aa...@pobox.com)
Hugs and backrubs -- I break Rule 6 http://rule6.info/
Androgynous poly kinky vanilla queer het Pythonista
"First one back from the bathroom gets to be the bottom."
ru.ig...@usask.ca
>ru.ig...@usask.ca wrote in message news:<beif1k$gdm$1...@tribune.usask.ca>...
>> are concerned). What indicates to the proponents that
>> non-standards discussion won't move in, at least not in
>> significant quantity? Is that the concern here?
>The success of the other fora. We don't see it as a highly likely
>problem.
Usenet activity does not behave the same as non-usenet fora in
this regard. Because readers here can select from multiple
categorized discussion areas from a list with very little
effort, the tendency to pick something with a name sufficiently
resembling their point of interest is higher than with something
like a mailing list, or web board where you have to think
about where the different fora reside (by application or
by address). It may also be easier for people to find a
newsgroup on the related topic than a mailing list or a
web board. Or are you saying non-standards readers will
stay with the non-usenet fora?
Often readers of other fora don't make the move to usenet (e.g.
control issues, volume issues, politics, politeness levels).
I can't remember if you indicated this in the RFD, but have you
checked with readers in those fora if they will read the group?
Otherwise, you end up relying on existing usenet readers, which
apparently are not that abundant.
Jim Riley
>TXSherry <sherr...@go.com> wrote:
>> The main problem imo would be if servers carried comp.std.csharp (most
>> likely) and did not carry the microsoft heirarchy (possibility), how
>> then would you get the off topic csharp *language* traffic on those
>> non-MS carrying servers to move from the std group to the "proper"
>> group, when there IS NO proper group for them to go to.
>
>I would suggest that those posters connect to the MS news-server. It's
>not like it costs money to do so or anything.
It is extra effort to switch to another server. At present, it is the
only alternative, so if people are interested in use of the language,
that is their only alternative.
It also suggests that c# is a proprietary product of Microsoft, which
begs the question of why there is a need for a group for discussing
standarization independent of Microsoft?
--
Jim Riley
Jim Riley
<joel.i...@intel.com> wrote:
>The reason why this should be put under the heading of comp.std.csharp is
>that it should be made clear that this a group focused on the C# standard and
>its content, and not on specific implementations.
It is wishful thinking that placing it under the heading of "std" will
make clear the intent or focus of the group, especially given the lack
of a visible alternative for the other traffic that will be attacted
by the name of the group.
--
Jim Riley
Devin L. Ganger
> It also suggests that c# is a proprietary product of Microsoft, which
> begs the question of why there is a need for a group for discussing
> standarization independent of Microsoft?
A simple check will show this suggestion to be false, though. There
is at least one non-Microsoft implementation of C# available now, though
not as full featured, and Microsoft has submitted CLI and C# to the ECMA
standards body.
The standards groups exist and the issues are real, even if the product
came from Microsoft initially.
--
Devin L. Ganger <de...@thecabal.org>
"Aikido is based around the central precept of letting an attack take its
natural course. You, of course, don't want to impede that natural flow
by being in its way." -- overheard on the PyraMOO
Nigel Perry
> It also suggests that c# is a proprietary product of Microsoft, which
> begs the question of why there is a need for a group for discussing
> standarization independent of Microsoft?
C# was originally developed by Microsoft. It has been standardised
through ECMA/ISO and there are now non-Microsoft implementations
(Mono, Portable Dot NET). It is not a proprietary product anymore.
It is the ECMA Standards group, not Microsoft, which has placed this
RFD.
Cheers,
Nigel
Nigel Perry
> REQUEST FOR DISCUSSION (RFD)
> unmoderated group comp.std.csharp
>
> This is a formal Request For Discussion (RFD) for the creation of
> the worldwide unmoderated newsgroup comp.std.csharp. This is not
> a Call for Votes (CFV); you cannot vote at this time. Procedural
> details are below.
>
> Newsgroup line:
> comp.std.csharp Discussions on the ECMA/ISO Common Language.
There was a cut'n'paste error when this RFD was posted (it was
submitted along with comp.std.cli and split beofre posting). The above
line should have read:
comp.std.csharp ECMA/ISO C# Standard
(the "Discussions on the" is implied). This is clear from the rest of
the RFD. I've checked with the moderator and this is not viewed as
requiring a new RFD. It will be fixed in the CFV (or in a second RFD
if one is needed for other reasons).
Apoligies for the error.
[Note this message has been delayed due to a Google bug:
due to a problem with google's posting software, your article,
which should have gone to news.groups (and possibly other groups),
has mistakenly been submitted to news.announce.newgroups, the
administrative group for the big-8. we have notified google
about this problem, and hope they shall fix their software soon.
]
Nigel Perry
In considering how and where to respond to the reported need for a
forum to discuss the Standard the ECMA Committee where of the opinion
that:
1) There is a perceived openess and neutrality regarding Usenet. The
main mailing lists are hosted company sites, and the other newsgroups
are in the microsoft.* heirarchy.
2) No other discussion groups on Standards were known to be on mailing
lists, they are on Usenet.
3) Discoverabilty: it is easy to find Usenet groups.
4) Usenet is better supported by search engines, such as Google.
So all in all Usenet and the comp.std heirarchy seems the best place.
Nigel
Jim Riley
<de...@thecabal.org> wrote:
>On Thu, 10 Jul 2003 17:24:47 -0500, Jim Riley <jim...@pipeline.com> wrote:
["it" in the following sentence refers to the fact that the only
newsgroup for discussing c# is on Microsoft's proprietary server
(albeit one that it sometimes more widely distributed)]
>> It also suggests that c# is a proprietary product of Microsoft, which
>> begs the question of why there is a need for a group for discussing
>> standarization independent of Microsoft?
>
>A simple check will show this suggestion to be false, though. There
>is at least one non-Microsoft implementation of C# available now, though
>not as full featured, and Microsoft has submitted CLI and C# to the ECMA
>standards body.
So if someone wants to discuss the non-Microsoft implementation they
would at present be directed to use the microsoft.* hierarchy, and
told if their server does not carry it, to use the Microsoft server?
--
Jim Riley
Sebastian Palm
"Nigel Perry" <ni...@cosc.canterbury.ac.nz> wrote in message
news:10576239...@isc.org...
> REQUEST FOR DISCUSSION (RFD)
> unmoderated group comp.std.csharp
>
> This is a formal Request For Discussion (RFD) for the creation of
> the worldwide unmoderated newsgroup comp.std.csharp. This is not
> a Call for Votes (CFV); you cannot vote at this time. Procedural
> details are below.
Many others have already commented on the lack of a comp.lang.csharp group,
which might, and in all probability *will*, lead to the proposed
comp.std.csharp being turned into a forum for implementation questions,
rather than standards discussion. And so, I have to wonder, being a (more or
less) total newbie to news.groups and not at all involved in the issue at
hand: Is there a chance of *getting* a comp.lang.csharp group? Is anyone
prepared to propose one?
SP
ru.ig...@usask.ca
>Many others have already commented on the lack of a comp.lang.csharp group,
>which might, and in all probability *will*, lead to the proposed
>comp.std.csharp being turned into a forum for implementation questions,
>rather than standards discussion. And so, I have to wonder, being a (more or
>less) total newbie to news.groups and not at all involved in the issue at
>hand: Is there a chance of *getting* a comp.lang.csharp group? Is anyone
>prepared to propose one?
If it becomes enough of a concern (to the proponents), they could
very well choose to ADD that to their current C# proposal. The ballot
would then have a YES/NO/ABSTAIN selection for each proposed group,
so that it is possible to create neither, both, or either group through
one ballot. BUT it would mean the proponents do the extra work of
determining the RATIONALE and building a CHARTER for the extra group,
which is not fun and is not something they have much interest in.
If they do not choose this option, and the group goes nuts with
implementation traffic, at some point standards folks will either
give up on the group, or someone will take the initiative and
propose a new group. The problem is that depending on the situation
and the approach taken, getting off-topic traffic out of a group
can be difficult. Things tend to work better if off-topic folks take
the initiative to pull traffic into their own group, rather than if
the standards folks take the initiative to try to push traffic out
of their group.
Nicholas Fitzpatrick
Jon Skeet <sk...@pobox.com> wrote:
>
>Would there be significant traffic for comp.lang.csharp though? Why
>would people post there rather than on the existing, well-used
>microsoft.* newsgroup? If it had been set up much earlier, I'm sure it
>would have taken off - but I suspect it's too late now.
If this is just a Microsoft product then, why not put the std group
over there? If it isn't just Microsoft, surely, there will be more
people who would post to a comp.* group, than who would go bother
to find a particular vendor's group.
Nick
Jim Riley
Perry) wrote:
Let me be as clear. This proposal by the ECMA Standards group is
short-sighted.
You may have anticipated that there would be opposition to the group
based on the relationship of c# with Microsoft. That, however, does
not mean that simply asserting independence from Microsoft makes it a
good proposal.
Imagine you were planning on building a house. I notice that the site
is at the bottom of a steep hill where a highway makes a sharp turn.
I point out that you will likely find busses and trucks parked in your
bedroom. You reply that you aren't interested in group sex, and you
will provide a map to those who miss the turn. This isn't going to
keep the vehicles out, and it won't keep the house being unhabitable.
Usenet has largely been consumerized, with the consumers vastly
outnumbering the producers. Or in the case of c#, users of the
language vastly outnumber implementors and standard-writers. It is
simply not realistic that the users of c# will limit themselves to
mailing lists or the microsoft.* groups, and then come over to the Big
8 group when they want to discuss language standards with the
implementors.
But if in the ultra-impropable case that it is only implementors and
standard-writers who are interested, there are unlikely to be enough
to warrant a group. It could be handled with a mailing list, or a
newsgroup on a private server.
As proposed:
comp.std.csharp
The group name or the intent of the proponents will magically keep the
unwanted traffic out, or it will somehow all find its way to a
proprietary group on a proprietary server or mailing lists.
Possible alternatives:
A) comp.lang.csharp
Users could discuss the language. Implementors and standard writers
could participate as well. If there is a need for a more-specific
standardization group, it can be created later.
B) comp.lang.csharp and
comp.lang.csharp.standardization
Having the two groups next to each other makes the relationship
between the groups clearer.
C) comp.lang.csharp and
comp.std.csharp
People might believe that the second group is for "standard" variant
of the language (the equivalent to standard Pascal or Basic).
D) comp.std.csharp (moderated)
You could keep the unwanted traffic out.
--
Jim Riley
Jim Riley
Perry) wrote:
>Jim Riley <jim...@pipeline.com> wrote in message news:<bej64e$2m7$1...@slb9.atl.mindspring.net>...
>> If you mean that "std" will somehow magically ward off discussion of
>> the language, I don't think that it will. That is the basis of my
>> whole argument.
>
>There are a number of other succesful fora where questions on language
>usage are asked and answered. Why would there really be a mass exodus
>of people from a working Q&A forum to a new one for the Standard so
>they can ask their "what's wrong with my for loop" question there?
This presumes that participation in such forums is static. The people
asking "what's wrong with my for loop" question are unlikely to have
subscribed to the group for the past seven years, but were looking for
a group to ask a question.
If you simply want to ask a question, subscribing to a mailing list is
a lot of work. Regular participants in a mailing list may become
annoyed if this type of question is repetitive.
People who prefer newsgroups may not know about the microsoft.* group,
or may not like microsoft.* groups for any number of reasons (e.g.
harder to access, tons of HTML-bloat, antipathy towards Microsoft,
different culture).
You are providing a solution for those people who either did not find
the other forums, or did not like using them. It really does not
matter that you didn't intend to provide a place for this discussion
or that you believed that everyone interested in discussing c# would
have found the alternative forums.
>Sure some language type questions will appear in a comp.std group, but
>will it really be of problematic proportions?
Are you satisfied with the nature of comp.std.c and comp.std.c++?
Isn't the most realistic expectation be that comp.std.csharp will be
"like comp.std.c and comp.std.c++ but for c#"?
> I expect not. This group
>has been proposed in response to a request for a Standards forum from
>people who haven't found such in the existing fora.
What was the specific request? Maybe the proposed solution (this RFD)
does not satisfy the request.
>> Standardization of c# is one aspect of the language, and would be best
>> served by containing all the discussion in a single group, or creating
>> adjacent subgroups so that the relationship is more obvious.
>
>Maybe a comp.lang would have been a good idea, and might yet be.
>However the existing fora are up, running, and working well. Would
>they migrate to a comp.lang?
There are many more users of c# than there are implementors or
standard-writers. Is it realistic that users who might have some
interest in standards will also use a group in an arena that is
foreign to them? Aren't you really arguing that these users prefer
mailing lists or the microsoft.* group, but will switch over to the
Big 8 for this type of discussion?
--
Jim Riley
Jim Riley
wrote:
>Jim Riley <jim...@pipeline.com> writes:
>> Russ Allbery <r...@stanford.edu> wrote:
>>> Jim Riley <jim...@pipeline.com> writes:
>>> I'm not sure that I see the distinction between those two topics.
>
>> "When I compiled my code with the -strictcompliance flag set, I got an
>> error message, what'd I do wrong?" is not really about standardization.
>
>It's about the standards and is a perfectly reasonable thing to discuss in
>a comp.std.* group. It also directly informs the standardization process
>not infrequently, since those sorts of discussions expose edge cases and
>unclear areas in the standard.
"I get an error message, what's wrong."
"You should ask on microsoft.*, this group is for discussing the
standardization of the language c#"
"I don't get that group."
"I'm not using the Microsoft compiler."
"This is the only *Usenet* group for c#"
>>> If it gets too much regular language use discussion, that would be an
>>> excellent justification for creating a new comp.lang.* group, yes?
>
>> And if they don't get enough votes to create that group? They're stuck
>> with the group as it is.
>
>Then there wasn't too much regular language use discussion to actually
>bother enough people to do something about it, was there?
Why split the group simply because it is misplaced, and not serving
its intended purpose?
--
Jim Riley
ru.ig...@usask.ca
Here's another way of looking at what Jim is saying. Consider all
users of usenet as potential posters of any C# group (if all C#
topics had groups). Of those, there is a definite number of usenet
users that would use a C# group if it existed. These users would
have discussions ranging from "what is C#?" to programming to standards.
Now remove all hypothetical C# specific groups and put in the standards
group. Where will all those folks with C# at the back of their minds
go when they decide to finally dig for info? Remember, all of these
users are already on usenet and so their first inclination may well be
to check usenet (e.g. via google search for "C#"). Many, if not most,
won't even try searching for a mailing list if there is ANY hit on C#,
opting instead to ask on the existing group for pointers.
Jon Skeet
> >Would there be significant traffic for comp.lang.csharp though? Why
> >would people post there rather than on the existing, well-used
> >microsoft.* newsgroup? If it had been set up much earlier, I'm sure it
> >would have taken off - but I suspect it's too late now.
>
> If this is just a Microsoft product then, why not put the std group
> over there?
That's been addressed in another post - it's not just MS, even though
it's principally MS.
> If it isn't just Microsoft, surely, there will be more
> people who would post to a comp.* group, than who would go bother
> to find a particular vendor's group.
Not *enough* more, IMO, given the already flourishing MS group. If
comp.lang.csharp had come into existence a year or so ago, it would
have had a good chance - I don't think it would have nearly such a
chance of success now.
Nicholas Fitzpatrick
Jon Skeet <sk...@pobox.com> wrote:
>
>Not *enough* more, IMO, given the already flourishing MS group. If
>comp.lang.csharp had come into existence a year or so ago, it would
>have had a good chance - I don't think it would have nearly such a
>chance of success now.
... and what happens when Microsoft EOLs the product in another
6 months, and replaces it with, say, dflat ...
I'd say create both groups ...
Nick
Nigel Perry
> As proposed:
>
> comp.std.csharp
>
> The group name or the intent of the proponents will magically keep the
> unwanted traffic out, or it will somehow all find its way to a
> proprietary group on a proprietary server or mailing lists.
>
>
> Possible alternatives:
>
> A) comp.lang.csharp
>
> Users could discuss the language. Implementors and standard writers
> could participate as well. If there is a need for a more-specific
> standardization group, it can be created later.
>
>
> B) comp.lang.csharp and
> comp.lang.csharp.standardization
>
> Having the two groups next to each other makes the relationship
> between the groups clearer.
>
>
> C) comp.lang.csharp and
> comp.std.csharp
>
> People might believe that the second group is for "standard" variant
> of the language (the equivalent to standard Pascal or Basic).
Given that comp.std is for standards, is this a known problem with the
other groups in there?
>
>
> D) comp.std.csharp (moderated)
>
> You could keep the unwanted traffic out.
Following on from a suggestion on the RFD for comp.std.cli, would
those concerned over the lack of a comp.lang.csharp to match
comp.std.charp be happier if the group name was one of:
comp.std.ecma-csharp
comp.std.iso-csharp
comp.std.ecma-iso-csharp
I.e. would adding the name of the Standards organisation(s) help?
TIA,
Nigel
Sebastian Palm
<ru.ig...@usask.ca> wrote in message
news:bems2j$jtd$1...@tribune.usask.ca...
Aah. I remember reading of a similar situation regarding
rec.arts.sf.written, where a rogue alt.* group was created by the vocal
locals to get rid of "offtopic" traffic - only to fall flat, until one of
the "offtopic" posters managed to push through a subgroup.
Because of the similarity of scope of a comp.lang.csharp group to many of
the other comp.lang.* groups, I think adapting an existing charter would be
a fairly simple deal. Coming up with a rationale would be a bit harder, but
doable. Then agai, I have absolutely no clue as to the traffic levels of the
existing microsoft.public.* group, and the likelyhood of a migration. Oh
well. Such is academia...
SP
Brian Palmer
> I remember reading of a similar situation regarding
> rec.arts.sf.written, where a rogue alt.* group was created by the vocal
> locals to get rid of "offtopic" traffic - only to fall flat, until one of
> the "offtopic" posters managed to push through a subgroup.
What exactly is a rogue alt.* group? alt.* is where anybody can
newgroup, anybody can rmgroup, so it doesn't make a lot of sense to
attach 'rogue' to any particular group (ignoring the binary issues).
But I think you're talking of rec.arts.sf.written.robert-jordan, yes?
--
If you want divine justice, die.
-- Nick Seldon
Mean Green Dancing Machine
>those concerned over the lack of a comp.lang.csharp to match
>comp.std.charp be happier if the group name was one of:
>
> comp.std.ecma-csharp
> comp.std.iso-csharp
> comp.std.ecma-iso-csharp
>
>I.e. would adding the name of the Standards organisation(s) help?
Not particularly. Unlike "CLI", there's no source of confusion for what
"csharp" means. I'd say that overall, I'm more concerned about the lack
of a comp.lang.* group for csharp than I am for CLI; I consider the
latter of more interest to people into computer esoterica. (I.e., how
many people really care about JVMs versus Java?)
--
--- Aahz <*> (Copyright 2003 by aa...@pobox.com)
Hugs and backrubs -- I break Rule 6 http://rule6.info/
Androgynous poly kinky vanilla queer het Pythonista
I support the RKAB
ba...@dmcom.net
>
> What exactly is a rogue alt.* group?
Over in alt.config it is generally accepted rogue if there is no control
message. Some look for a proper formatted control message that includes
a charter. After that, fewer look at things like it being discussed,
that it does not duplicate an existing group, revenge groups, etc.
--
news:alt.pagan FAQ at http://www.dmcom.net/bard/altpag.txt
news:alt.religion.wicca FAQ at http://www.dmcom.net/bard/arwfaq2.txt
news:news.groups FAQ at http://www.dmcom.net/bard/ngfaq.txt
Want a new group FAQs http://web.presby.edu/~nnqadmin/nnq/ncreate.html
ba...@dmcom.net
<alt.config added>
>
> On Sat, 12 Jul 2003 13:00:27 -0400, ba...@dmcom.net wrote:
>
> >Brian Palmer wrote:
> >
> >>
> >> What exactly is a rogue alt.* group?
> >
> >Over in alt.config it is generally accepted rogue if there is no control
> >message.
>
> way. But calling something "rogue" doesn't make it so. Some of those
> folks seem to have forgotten the purpose of alt.config, which is to
> advise, not to make rules.
Well alt.* was created by a control message that providers acepted. As
for vocals, it becomes rather hard to provide advice if it is not
provided.
>
> > Some look for a proper formatted control message that includes
> >a charter. After that, fewer look at things like it being discussed,
> >that it does not duplicate an existing group, revenge groups, etc.
>
> All that matters is whether enough news providers pick it up for good
> propagation. The things alt.config looks at are supposed to help
> people who want to create a newsgroup get it picked up, but there is
> no hard data that any of those things matter to a significant number
> of providers. And an alt.* newsgroup that is being used, whether or
> not it has a charter or duplicates another newsgroup, can hardly be
> considered "rogue."
And in some cases providers do not have an control message. Just
offered reasons why some advisors might call an alt.* group rogue.
>
> BW
> (ex-alt.configger)
You might onsider visoting again as it appears noise is less (or I got
used to it).
Adam H. Kerman
>>>What exactly is a rogue alt.* group?
>>Over in alt.config it is generally accepted rogue if there is no control
>>message.
>Not really. There are certain vocal alt.config posters who feel that
>way. But calling something "rogue" doesn't make it so.
It's a misnomer. News administrators make the rules. They wish to create,
or allow to be created, a newsgroup on behalf of a proponent who won't sent
a newgroup for whatever reason, they get to do that.
I consider those groups to be local groups named into alt, even though the
articles are fed to other servers outside the network. It doesn't make any
difference if those groups exist on some server (or a handful of servers
on different networks). I don't agree with those that say the situation
should be "corrected" with a newgroup at a later date; there never was a
"problem" to begin with.
>Some of those folks seem to have forgotten the purpose of alt.config,
>which is to advise, not to make rules.
Advise whom? Those proponents don't show up in alt.config; they propose the
groups directly to their own news administrators.
>> Some look for a proper formatted control message that includes a charter.
Some look only to see that the newgroup was archived and don't even bother to
look to see if the newgroup message included a charter.
>>After that, fewer look at things like it being discussed, that it does
>>not duplicate an existing group, revenge groups, etc.
>All that matters is whether enough news providers pick it up for good
>propagation.
You don't think the traffic a group eventually attracts matters?
>The things alt.config looks at are supposed to help people who want to
>create a newsgroup get it picked up, but there is no hard data that any
>of those things matter to a significant number of providers. And an alt.*
>newsgroup that is being used, whether or not it has a charter or duplicates
>another newsgroup, can hardly be considered "rogue."
You are aware of alt groups without newgroups that are widely created on
servers around the world? Do tell.
Jim Riley
Perry) wrote:
>Jim Riley <jim...@pipeline.com> wrote in message news:<bemv0q$kpk$1...@slb6.atl.mindspring.net>...
>> As proposed:
>>
>> comp.std.csharp
>>
>> The group name or the intent of the proponents will magically keep the
>> unwanted traffic out, or it will somehow all find its way to a
>> proprietary group on a proprietary server or mailing lists.
>>
>>
>> Possible alternatives:
>>
>> A) comp.lang.csharp
>>
>> Users could discuss the language. Implementors and standard writers
>> could participate as well. If there is a need for a more-specific
>> standardization group, it can be created later.
>>
>>
>> B) comp.lang.csharp and
>> comp.lang.csharp.standardization
>>
>> Having the two groups next to each other makes the relationship
>> between the groups clearer.
>>
>> C) comp.lang.csharp and
>> comp.std.csharp
>>
>> People might believe that the second group is for "standard" variant
>> of the language (the equivalent to standard Pascal or Basic).
>
>Given that comp.std is for standards, is this a known problem with the
>other groups in there?
It is a myth that groups are hierarchical, or that their names reflect
that hierarchical structure. In the way, way, back there was a
suggestion that would implement groups as nested subgroups (net.sport
would contain all messages about sports, net.sport.baseball the subset
pertaining to baseball, etc.). This never went any further.
Originally group names were limited to 14 characters total (early
implementations used the group name as a directory name, with each
article stored as a file). comp.dcom.* is so-named rather than
comp.datacomm.* because net.dcom permits a longer name, *not* more
space for additional name components.
The 14-character total limit was overcome by mapping newsgroup names
to hierarchical file structures (articles for foo.bar.baz were stored
in foo/bar/baz, messages for alt.swedish.chef.bork.bork.bork in
alt/swedish/chef/bork/bork/bork. So at that time, "." was just
another character in the group name set (and used as a way of
extending names, since strings of [0-9a-z_\-] were limited to spans of
14 characters. That 14-character limit has since been extended.
Of course, similar names may indicate associated topics, but *users*
quite often will disregard parts of the name, especially since most
searching is not on structured names, but rather substrings (which
explains the posts about the Eiffel Tower in comp.lang.lisp.frantz and
beer-making in alt.binaries.hebrew.fonts.
Let's look at the groups that start with "comp.std."
comp.std.misc
Light traffic, too broad. I disagree totally with the suggestion that
this group be used to "build" traffic.
comp.std.announce
Moderated and inactive. Again it is too broad a topic (unless perhaps
it were limited to programming language standards).
comp.std.unix
Moderated, with light sporadic traffic. The moderation appears to
have some links to the actual standardization effort, and appears more
to have somewhat of an announcement rather than a discussion flavor.
comp.std.internat (sic)
An old group, originally created by Europeans who had interest in
topics such as character sets beyond ASCII. From time to time will
get included in cross-posts from other groups, but doesn't seem to
have much if any traffic of its own. If comp.std was regarded as
*the* standards hierarchy, this group would have more traffic.
comp.std.wireless
May come the closest to what you want, but is very low volume. It may
get some protection because it is an area where people understand the
difference between standard and implementation, and those interested
strictly in use will tend to look in groups associated with their
particular platform or computer type.
This brings us to the language groups,
comp.std.c
comp.std.c++
comp.lang.lisp
The Lisp group is moderated and inactive. At one time there was a
moderated Mumps group (and no corresponding comp.lang).
comp.std.c was moderated at one time. This was back when K&R was a de
facto standard, and ANSI c was still prospective. To some extent
"standard" C can be considered a variant of C, and the traffic in
comp.std.c seems to reflect that (i.e. "comp.std.c" is interpreted to
mean "about the (computer language) standard C").
comp.lang.c and comp.lang.c++ are extremely high volume groups.
Moderated groups have been created to control the volume, and perhaps
at least in intent to weed out some of the advocacy posts and homework
problems. Some of the traffic in comp.std.c and comp.std.c++ may
simply be overflow from those groups. Other traffic may be
cross-posted.
Let's consider some types of grossly-stereotyped computer users.
a) Those who believe that Wintel is a synonym for computer.
b) Those who believe that Wintel is not a computer.
c) Those who believe that Wintel is one type of computer.
I assume that you are interested primarily in attracting those in
Group C, and will tolerate those in Group B as long as they don't
insist on pushing their viewpoint too strenuously. Those in Group A
might show up, but not quite not understand what your group is really
about.
People in Groups B and C will tend to not want to use the microsoft.*
groups. If they are interested in c#, it will be in "standard" c#
rather than the Microsoft product. Given that there is no other c#
newsgroup visible to them, they will treat the group comp.std.csharp
as comp.lang.csharp.
On the other hand, people in Group A tend to treat any group with a
name associated with a Microsoft product as being about the Microsoft
product (e.g. comp.lang.visual and comp.windows, even before Bill
Gates invented X(P) Windows.). You will get all this traffic as well.
You might also pick up some traffic that wants to know if c# is
Microsoft's version of c++.
Absent a "comp.lang.csharp", "comp.std.csharp" will be treated as if
it were. Your only hope would be that there is little or no interest
in c#. But that would either mean that people are interested in the
standardization of c# but not c# itself OR that there is little
interest in your specific sub-topic.
Unless you want "comp.std.csharp" to be comp.lang.csharp in every
sense but the actual name, then you either need moderation or you need
an actual comp.lang.csharp. Even then you may need other clues to
indicate the distinction between your group and comp.lang.csharp. My
inclination would be to place your group next to comp.lang.csharp.
Yours is more a sub-topic of c# than a sub-topic of computer
standards.
>> D) comp.std.csharp (moderated)
>>
>> You could keep the unwanted traffic out.
>
>Following on from a suggestion on the RFD for comp.std.cli, would
>those concerned over the lack of a comp.lang.csharp to match
>comp.std.charp be happier if the group name was one of:
>
> comp.std.ecma-csharp
> comp.std.iso-csharp
> comp.std.ecma-iso-csharp
>
>I.e. would adding the name of the Standards organisation(s) help?
There is a comp.protocol.iso. It gets quite a bit of queries about
the image format for CDs. The person who creates a name for a concept
may understand the derivation. The person who reads the name may not
be able to do the reverse.
p.s. a search of "cli" on www.iso.org finds SQL/CLI and not the
standard for the Common Language Infrastructure.
p.p.s. using the name of ISO would probably confuse, and people may
not be willing to spend $50 to get a copy of a message posted to the
group.
--
Jim Riley
Mean Green Dancing Machine
Thank you for cogently clarifying my muddled subconscious reasoning for
pushing comp.lang.csharp. In other words, "Me, too!"
To others (specifically including Russ): I understand that this isn't a
completely accurate characterization of microsoft.* groups, but I think
the basic reasoning is sound.
Nigel Perry
> In article <bfd22a3a.03071...@posting.google.com>,
> Nigel Perry <ni...@cosc.canterbury.ac.nz> wrote:
> >
> >Following on from a suggestion on the RFD for comp.std.cli, would
> >those concerned over the lack of a comp.lang.csharp to match
> >comp.std.charp be happier if the group name was one of:
> >
> > comp.std.ecma-csharp
> > comp.std.iso-csharp
> > comp.std.ecma-iso-csharp
> >
> >I.e. would adding the name of the Standards organisation(s) help?
>
> Not particularly. Unlike "CLI", there's no source of confusion for what
> "csharp" means. I'd say that overall, I'm more concerned about the lack
> of a comp.lang.* group for csharp than I am for CLI; I consider the
> latter of more interest to people into computer esoterica. (I.e., how
> many people really care about JVMs versus Java?)
It isn't quite the same thing. Though a lot (100+?) of languages have
been compiled for the JVM only one is really well known - Java. The
CLI is designed for multiple languages and already there are many
which target it (Fortran, Cobol, Ada 95, Mondrian, Haskell [limited],
Mercury, Component Pascal, Perl [in progress], C*, VB, etc.). So its
hardly "esoteric". But this should be on the CLI RFD...
Intel News
(comp.lang.c, comp.std.c), there may be, in time, the same for C#.
The proposal for this group is for the standard only because the domain of
the request is coming from the standardization perspective. The goal is to
establish the standard group first -- what happens with a "lang" group
remains to be seen, but I believe the two groups can be considered
orthogonal just as with the case of C and C++.
- Joel
Jim Riley
<joel.i...@intel.com> wrote:
>Just as there are two relevant groups for C language, for example
>(comp.lang.c, comp.std.c), there may be, in time, the same for C#.
>
>The proposal for this group is for the standard only because the domain of
>the request is coming from the standardization perspective.
This perspective is the fundamental flaw with the current proposal.
The proponents want to create de jure comp.std.csharp, but they are
creating de facto comp.lang.csharp. It is their perspective that is
making them not recognize this. Not wanting something to happen does
not mean it will not happen.
>The goal is to
>establish the standard group first -- what happens with a "lang" group
>remains to be seen, but I believe the two groups can be considered
>orthogonal just as with the case of C and C++.
This goal is not achievable unless the group is moderated. Otherwise
people who want a "lang" group will crash the party, and they
outnumber you.
comp.std.c and comp.std.c++ were created after their respective
comp.lang.* groups, and comp.std.c. At this point, they really don't
serve the function that you expect comp.std.csharp to perform.
--
Jim Riley
Bill Aten
unmoderated group comp.std.csharp
Newsgroups line:
comp.std.csharp ECMA/ISO C# Programming Language Standard.
Votes must be received by 23:59:59 UTC, 29 Aug 2003.
This vote is being conducted by a neutral third party. Questions about
the proposed group should be directed to the proponent.
Proponent: Nigel Perry <ni...@cosc.canterbury.ac.nz>
Proponent: Rex Jaeschke <r...@rexjaeschke.com>
Votetaker: Bill Aten <bi...@netagw.com>
RATIONALE: comp.std.csharp
There are no newsgroups to discuss the ECMA/ISO Standards for C#.
There are multiple implementations of this standard; including the
Microsoft product, Mono, Rotor and DotGNU; and a forum for the
discussion of the Standard and possible future directions would be of
benefit to the community. The ECMA Technical Group for C#
are proposing this newsgroup and will monitor the postings.
CHARTER: comp.std.csharp
The purpose of this newsgroup shall be to establish and maintain a
forum for the open discussion of issues related to the ECMA/ISO C#
Standard. Topics may include but are not limited to matters such as the
following:
- Meaning of the Standard
- Implementation of the Standard
- Possible errors/omissions in the Standard
- Possible future directions of the Standard
ECMA and ISO have formal procedures for input to, and reporting errors in,
Standards. This group will in no way replace those procedures. The group
is intended as a forum for the community. However the ECMA Technical
Group for the Standard will monitor and take note of discussions on the
newsgroup.
END CHARTER.
HOW TO VOTE:
Extract the ballot from the CFV by deleting everything before and after
the "BEGINNING OF BALLOT" and "END OF BALLOT" lines. Don't worry about
the spacing of the columns or any quote characters (">") that your
reply inserts.
PLEASE, do not send the entire CFV back to me as this mail is archived.
Mark the ballot and then MAIL it to: <cshar...@netagw.com>
Just "replying" to this message should work, but check the "To:" line.
In order to properly record your vote, please provide your REAL NAME
(or established Usenet handle) and indicate your desired vote in the
appropriate locations inside the ballot.
Examples of how to properly indicate your vote:
[ YES ] example.yes.vote
[ NO ] example.no.vote
[ ABSTAIN ] example.abstention
[ CANCEL ] example.cancellation
DO NOT modify, alter or delete any information in this ballot!
If you do, the voting software will probably reject your ballot.
If you do not receive an acknowledgment of your vote within three
days, contact the votetaker about the problem. You are responsible
for reading your ack and making sure your vote is registered correctly.
======= BEGINNING OF BALLOT: Delete everything BEFORE this line =======
|----------------------------------------------------------------------
| Official CFV Name: comp.std.csharp
| Usenet Voting Ballot <CSC-0001> (Do not remove this line!)
|----------------------------------------------------------------------
| Please provide your real name, or your vote may be rejected.
| Established Usenet handles are also acceptable. Place ONLY your name
| (ie. do NOT include your e-mail address or any other information;
| ONLY your name) directly after the colon in "Voter name:" on the
| following line.
|----------------------------------------------------------------------
| Voter name:
|----------------------------------------------------------------------
| Insert YES, NO, ABSTAIN, or CANCEL inside the brackets for each
| newsgroup listed below (do not delete the newsgroup name):
|
| Your Vote Newsgroup
| --------- ---------
| [ ] comp.std.csharp
|
|----------------------------------------------------------------------
======= END OF BALLOT: Delete everything AFTER this line ==============
IMPORTANT VOTING PROCEDURE NOTES:
Standard Guidelines for voting apply. Only one vote per person, no
more than one vote per account. Votes must be mailed directly from
the voter to the votetaker. Anonymous, forwarded, or proxy votes
are not valid. Votes mailed by WWW/HTML/CGI forms are considered
to be anonymous votes.
Vote counting is automated. Failure to follow these directions may
mean that your vote does not get counted. If you do not receive an
acknowledgment of your vote within three days, contact the votetaker
about the problem. It's your responsibility to make sure your vote
is registered correctly. Duplicate votes are resolved in favor of
the most recent valid vote. Names, addresses, and votes of all voters
will be published in the final voting results post.
DO NOT redistribute this CFV in any manner whatsoever. The purpose of
a Usenet vote is to determine the genuine interest of persons who would
read a proposed newsgroup. Soliciting votes from disinterested parties
defeats this purpose. Only the votetaker, the news.announce.newgroups
moderator, and the proponent (if specifically authorized by the votetaker)
are permitted to distribute copies of this CFV.
Distribution of pre-marked or otherwise modified copies of this CFV is
generally considered voting fraud and should be reported immediately to
the votetaker or the UVV <con...@uvv.org>. In cases where voting fraud
is determined to have occurred, it is standard operating procedure to
delete ALL votes submitted by the violator. When in doubt, ask the
votetaker.
DISTRIBUTION:
The only official sources for copies of this CFV are the locations listed
below, the UVV web site at http://www.uvv.org/, and the votetaker's e-mail
CFV server which can be reached at <csharp-cf...@netagw.com>.
This CFV has been posted to the following newsgroups:
news.announce.newgroups
news.groups
Bill Aten
Bill Aten
unmoderated group comp.std.csharp
RATIONALE: comp.std.csharp
CHARTER: comp.std.csharp
END CHARTER.
HOW TO VOTE:
| Usenet Voting Ballot <CSC-0002> (Do not remove this line!)
IMPORTANT VOTING PROCEDURE NOTES:
DISTRIBUTION:
news.announce.newgroups
news.groups
comp.std.csharp - Ack Bounce List
------------------------------------------------------------------------------
No bounced acknowledgments at this time
--
Bill Aten, UVV <bi...@netagw.com>
Bill Aten
unmoderated group comp.std.csharp fails 60:16
Voting closed at 23:59:59 UTC, 29 Aug 2003.
This vote was conducted by a neutral third party. Questions about the
proposed group should be directed to the proponent.
Proponent: Nigel Perry <ni...@cosc.canterbury.ac.nz>
Proponent: Rex Jaeschke <r...@rexjaeschke.com>
Votetaker: Bill Aten <bi...@netagw.com>
There were 76 valid YES/NO votes submitted during the voting period. Each
proposed newsgroup, in order to pass, must have at least 2/3 YES votes and at
least 100 more YES than NO votes. The results are as follows:
comp.std.csharp results - 76 valid (YES & NO) votes
Yes No : 2/3? >100? : Pass? : Group
---- ---- : ---- ----- : ----- : -------------------------------------------
60 16 : Yes No : No : comp.std.csharp
3 abstaining votes
The proposal failed.
There is a five day discussion period after these results are posted.
Unless serious and significant allegations of voting irregularities are
raised, the proposal may not be voted on again for six months.
The remainder of the RESULT contains:
Newsgroups Line
Rationale
Charter
Final Voting Acknowledgements
NEWSGROUPS LINE:
comp.std.csharp ECMA/ISO C# Programming Language Standard.
RATIONALE: comp.std.csharp
There are no newsgroups to discuss the ECMA/ISO Standards for C#.
There are multiple implementations of this standard; including the
Microsoft product, Mono, Rotor and DotGNU; and a forum for the
discussion of the Standard and possible future directions would be of
benefit to the community. The ECMA Technical Group for C#
are proposing this newsgroup and will monitor the postings.
CHARTER: comp.std.csharp
The purpose of this newsgroup shall be to establish and maintain a
forum for the open discussion of issues related to the ECMA/ISO C#
Standard. Topics may include but are not limited to matters such as the
following:
- Meaning of the Standard
- Implementation of the Standard
- Possible errors/omissions in the Standard
- Possible future directions of the Standard
ECMA and ISO have formal procedures for input to, and reporting errors in,
Standards. This group will in no way replace those procedures. The group
is intended as a forum for the community. However the ECMA Technical
Group for the Standard will monitor and take note of discussions on the
newsgroup.
END CHARTER.
FINAL VOTING ACKNOWLEDGEMENTS:
comp.std.csharp - Final Voter List
NOTE: This is not [to be used as] a mailing list. The email addresses
are provided only to help verify the validity of the interest poll.
Voted YES
------------------------------------------------------------------------------
aminggs [at] yahoo.co.uk Andrew Inggs
andersh [at] microsoft.com Anders Hejlsberg
arch.robison [at] intel.com Arch D. Robison
arild.fines [at] broadpark.no Arild Fines
asnatu [at] msn.com ABHAY NATU
bap [at] shrdlu.com Bernard Peek
bouvin [at] daimi.au.dk Niels Olof Bouvin
Brian.Inglis [at] SystematicSw.ab.ca Brian Inglis
chris.huson [at] intel.com Chris Huson
chris [at] kzim.com Christopher Robin Zimmerman
chriskrolczyk [at] hotmail.com Chris Krolczyk
christian [at] christiannagel.com Christian Nagel
cmeerw_vote [at] fastrun.at Christof Meerwald
croyle [at] gelemna.org Don Croyle
cuhulain_98 [at] yahoo.com The Ranger
davep [at] davep.org Dave Pearson
david [at] farrar.com David Farrar
dball [at] booksnbytes.com David Ball
devin [at] thecabal.org Devin L. Ganger
dfrost [at] maths.tcd.ie Dermot Frost
Dmitriy.Zaslavskiy [at] morganstanley.com Dmitriy Zaslavskiy
dougbob [at] charter.net D. David OBrian
Ekkehard [at] Uthke.de Ekkehard Uthke
fabian.schmied [at] fhs-hagenberg.ac.at Fabian Schmied
fjh [at] cs.mu.oz.au Fergus Henderson
fungus [at] OCF.Berkeley.EDU Hank Fung
geoff.wilson [at] dsl.pipex.com Geoff Wilson
ggw [at] wolves.durham.nc.us Gregory "Wolfe" Woodbury
grantri [at] microsoft.com Grant Richins
ifette [at] comcast.net Ian Fette
jdg [at] diogenes.sacramento.ca.us John David Galt
jeffrey [at] carlyle.org Jeffrey Carlyle
joe.e.daly [at] intel.com Joe Daly
joel.i.marcey [at] intel.com Joel Marcey
jonk [at] avanade.com Jon Kale
kadhim [at] fsw.fujitsu.com Basim Kadhim
klaas [at] cs.dal.ca Klaas
mbw [at] MultiParadigm.com Miles B. Whitener
mgk25 [at] cl.cam.ac.uk Markus Kuhn
mgm321 [at] msn.com Michael Montwill
nigel [at] cosc.canterbury.ac.nz Nigel Perry
no.spam [at] kolumbus.fi Vesa Karjalainen
perezgus [at] hotmail.com Gus Perez
peterhal [at] microsoft.com Peter Hallam
rick [at] kinitos.com Rick Byers
Rune [at] Pronto.TV Rune Huseby
sbfaulds [at] ihug.co.nz Stuart Brodie Faulds
ScottA [at] avanade.com Scott B. Arbeit
shrao [at] nyx.net Shrisha Rao
skeet [at] pobox.com Jon Skeet
smlucas [at] famvid.com Steven Lucas
supasam [at] zoot.net.nz Sam Perry
t-panipe [at] microsoft.com Panagiotis G. Ipeirotis
tim [at] sneath.org Tim Sneath
tplum [at] plumhall.com Thomas Plum
usenet-karen [at] knauerhase.com Karen Knauerhase
usenet-rob [at] knauerhase.com Rob Knauerhase
vpdura [at] hiwaay.net Vic Dura
winchester [at] telia.com Sebastian Palm
zsh [at] cs.rochester.edu ShengHuo Zhu
Voted NO
------------------------------------------------------------------------------
cbarber [at] curl.com Christopher Barber
dc [at] panix.com David W. Crawford
gprrspw [at] mindspring.com G.P. Ryan
jimrtex [at] pipeline.com Jim Riley
julesd [at] programmer.net Jules Dubois
mmontcha [at] OregonVOS.net Matthew Montchalin
naddy [at] mips.inka.de Christian Weisgerber
nfitz [at] sentex.net Nicholas Fitzpatrick
pan [at] syix.com Pan
psmyth [at] gmx.net Peter Smyth
rick [at] bcm.tmc.edu Richard Miller
shrdlu [at] deaddrop.org Etaoin Shrdlu
squid [at] panix.com Yeoh Yiu
stainles [at] realtime.net Dwight Brown
zed [at] resonant.org Zed Pobre
zimnyzenon [at] interia.pl Zenobiusz Zimny
Voted ABSTAIN
------------------------------------------------------------------------------
aahz [at] pobox.com Aahz
cdsmith [at] twu.net Chris Smith
van.ette [at] inter.nl.net Robert-Jan van Ette
ba...@dmcom.net
>
> RESULT
> unmoderated group comp.std.csharp fails 60:16
*siges* so much for half pass have fail, three down now.
Markus Kuhn
Rather disappointing that two perfectly sensible, useful and
uncontroversion groups like comp.std.{cli,csharp} didn't make it.
With the continuing decline in active voter participation, isn't it
time to adjust the limits to the statistics of recent votes?
Requiring only at least ~50 YES votes would seem a much more reasonable
level at a time, where hardly any vote gets more than 100 voters.
Suggestion:
How about an adaptive rule under which the minimum required YES vote limit
has to be reviewed by the UVV every 29 February (that is every ~4 years
starting 29 February 2004), and should be adjusted to 75% of the average
vote turnout over the last 4 years, rounded to the nearest multiple of 25?
Example
If the 65:23 and 60:16 results of comp.std.{cli,csharp} were the
only votes that happened in the last adjustment period period, then
the new YES limit would have to be set to
10*round((65+23 + 60+16)/2 * 0.75 / 10) = 60
Is this a completely hopeless idea or worth a formal RFD?
Markus
--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Bill Cole
n03W36...@cl.cam.ac.uk (Markus Kuhn) wrote:
> :-(
>
> Rather disappointing that two perfectly sensible, useful and
> uncontroversion groups like comp.std.{cli,csharp} didn't make it.
>
> With the continuing decline in active voter participation, isn't it
> time to adjust the limits to the statistics of recent votes?
>
> Requiring only at least ~50 YES votes would seem a much more reasonable
> level at a time, where hardly any vote gets more than 100 voters.
Why is that change rational? Keep in mind that the current limit dates
from a time when there were a couple orders of magnitude fewer total
users.
The 'problem' of Big 8 newsgroups failing is not a problem with the
system of newsgroup creation.
> Suggestion:
>
> How about an adaptive rule under which the minimum required YES vote limit
> has to be reviewed by the UVV every 29 February (that is every ~4 years
> starting 29 February 2004), and should be adjusted to 75% of the average
> vote turnout over the last 4 years, rounded to the nearest multiple of 25?
>
> Example
>
> If the 65:23 and 60:16 results of comp.std.{cli,csharp} were the
> only votes that happened in the last adjustment period period, then
> the new YES limit would have to be set to
>
> 10*round((65+23 + 60+16)/2 * 0.75 / 10) = 60
>
> Is this a completely hopeless idea or worth a formal RFD?
Hopeless.
Even if the result is more successful proposals, that only really looks
good from the perspective of news.groupies. Lowering the bar so that
more ghost town groups get created does not help Usenet. Proposals that
can't attract 100 voters have either been grossly mismanaged by
proponents, or reflect topics that there really is not a Usenet audience
for.
--
Now where did I hide that website...
ba...@dmcom.net
>
> :-(
>
> Rather disappointing that two perfectly sensible, useful and
> uncontroversion groups like comp.std.{cli,csharp} didn't make it.
>
> With the continuing decline in active voter participation, isn't it
> time to adjust the limits to the statistics of recent votes?
>
> Requiring only at least ~50 YES votes would seem a much more reasonable
> level at a time, where hardly any vote gets more than 100 voters.
The average number of Yes votes this year (after last 3 results posted)
is 140.6 Yes and 16.7 No there are voters out there.
>
> Suggestion:
>
> How about an adaptive rule under which the minimum required YES vote limit
> has to be reviewed by the UVV every 29 February (that is every ~4 years
> starting 29 February 2004), and should be adjusted to 75% of the average
> vote turnout over the last 4 years, rounded to the nearest multiple of 25?
>
> Example
>
> If the 65:23 and 60:16 results of comp.std.{cli,csharp} were the
> only votes that happened in the last adjustment period period, then
> the new YES limit would have to be set to
>
> 10*round((65+23 + 60+16)/2 * 0.75 / 10) = 60
>
> Is this a completely hopeless idea or worth a formal RFD?
>
Afraid not worthy of RFD.
157 * .75 = 117.75 thus making it harder to pass groups then it is now.
Don Aitken
wrote:
The problem is not with the creation process, but with the lack of a
working *removal* process. It is never going to be possible to predict
with any certainty whether a group will succeed or not. If non-working
groups could be removed, that would not be a problem.
--
Don Aitken
Todd Michel McComb
Markus Kuhn <n03W36...@cl.cam.ac.uk> wrote:
>Rather disappointing that two perfectly sensible, useful and
>uncontroversion groups like comp.std.{cli,csharp} didn't make it.
Disappointing, perhaps, but it was a virtual certainty. The
proponents were unwilling to seek voters. Neither of these proposals
was sent to even a single comp.* group. While it might have been
disappointing to some of you who wanted the groups, we don't really
enjoy having our time wasted in this way either.
Todd McComb
mcc...@medieval.org
The Ranger
news:bj1olu$k5q$2...@pegasus.csx.cam.ac.uk...
> Rather disappointing that two perfectly sensible, useful and
> uncontroversion groups like comp.std.{cli,csharp} didn't make it.
The final votes dictated otherwise for both proposals.
> With the continuing decline in active voter participation, isn't it
> time to adjust the limits to the statistics of recent votes?
>
> Requiring only at least ~50 YES votes would seem a much more
> reasonable level at a time, where hardly any vote gets more than
> 100 voters.
[snip]
And when the groups can't maintain the level of activity you were seeking
and become silent? What do you propose for that?
I might not like [some of] the result but I do understand the need to set
the ratios of votes required for a group to become live.
The Ranger
Markus Kuhn
>The problem is not with the creation process, but with the lack of a
>working *removal* process. It is never going to be possible to predict
>with any certainty whether a group will succeed or not. If non-working
>groups could be removed, that would not be a problem.
How about a new rule that a group that achieved only a lower YES vote
is still created, but only for a probation period of 12 months.
After the end of the probation period, a confirmation vote will
have to succeed to keep it alive. This way, votes would be based more
on actually observed user needs, and people had a year time to find
out whether the group interests them or not. And most important of all,
the group itself can be used to target the most competent group of
voters directly, namely the actual users of the group.
Bill Cole
n03W36...@cl.cam.ac.uk (Markus Kuhn) wrote:
> Don Aitken <don-a...@freeuk.com> writes:
> >The problem is not with the creation process, but with the lack of a
> >working *removal* process. It is never going to be possible to predict
> >with any certainty whether a group will succeed or not. If non-working
> >groups could be removed, that would not be a problem.
>
> How about a new rule that a group that achieved only a lower YES vote
> is still created, but only for a probation period of 12 months.
> After the end of the probation period, a confirmation vote will
> have to succeed to keep it alive. This way, votes would be based more
> on actually observed user needs, and people had a year time to find
> out whether the group interests them or not. And most important of all,
> the group itself can be used to target the most competent group of
> voters directly, namely the actual users of the group.
I think you missed Mr. Aitken's perfectly true and relevantpoint: there
is no working removal process. Many years ago a stream of vandals abused
the automated group creation and removal gadgetry to the point where
many news servers stopped automating any group changes and even though
it is now feasible to re-enable automatic group creation and deletion
for Big 8 groups, a very large number of sites have not done so. As a
result new group creation is a little creaky, but is aided by users
pestering their news providers. Group removal has no such assistance, so
even when a group is formally removed, it will live on as a ghost at a
very large number of sites.
I offer as evidence: misc.kids.consumers, misc.jobs.offered,
rec.arts.comics.{other-media, alternative,european}. All of those have
formally been removed in the past 3 years. All remain in the active list
of at least one major US provider (SBC) and probably in many other
places.
BarB
wrote:
>In article <bj1olu$k5q$2...@pegasus.csx.cam.ac.uk>,
>Markus Kuhn <n03W36...@cl.cam.ac.uk> wrote:
>>Rather disappointing that two perfectly sensible, useful and
>>uncontroversion groups like comp.std.{cli,csharp} didn't make it.
>
>Disappointing, perhaps, but it was a virtual certainty. The
>proponents were unwilling to seek voters.
Were they unwilling or did they not know the importance of promoting the
groups? Were they told and refused to listen? I didn't follow the
discussion, but it has seemed to me in the past that news groupies have
many times failed to get that message across.... not that they haven't
tried.:(
BarB
Jim Riley
wrote:
>Suggestion:
>
>How about an adaptive rule under which the minimum required YES vote limit
>has to be reviewed by the UVV every 29 February (that is every ~4 years
>starting 29 February 2004), and should be adjusted to 75% of the average
>vote turnout over the last 4 years, rounded to the nearest multiple of 25?
The problem is that we don't know what level of support and interest
existing groups would have. If we knew that there were existing
groups that were OK, yet couldn't get 60 YES votes, we could add the
proposed groups with little concern.
If there were a survey of interest, in which people could express
interest in continuation of existing groups, as well as creation or
conversion of existing groups, we could then set some threshhold. If
an existing group were among the 5% least popular, and couldn't reach
that level with a specific call for interest it would be removed. New
groups that had more interest than the 5% least popular could be
created.
--
Jim Riley
Markus Kuhn
>>proponents were unwilling to seek voters.
>
>Were they unwilling or did they not know the importance of promoting the
>groups? Were they told and refused to listen?
Last time I made an RFD/CFV (misc.metric-system in Summer 2002),
I was told by the UVV documentation that a proponent is expected
to show some restraint in campaining. I did, and lost the vote due to
a lack of participants. People are at present *NOT* told about
the importance of promoting groups, on the contrary, they are
actively discouraged.
ba...@dmcom.net
>
> >On 2 Sep 2003 07:54:04 -0700, mcc...@medieval.org (Todd Michel McComb)
> >wrote:
> >>Disappointing, perhaps, but it was a virtual certainty. The
> >>proponents were unwilling to seek voters.
> >
> >Were they unwilling or did they not know the importance of promoting the
> >groups? Were they told and refused to listen?
>
> Last time I made an RFD/CFV (misc.metric-system in Summer 2002),
> I was told by the UVV documentation that a proponent is expected
> to show some restraint in campaining. I did, and lost the vote due to
> a lack of participants. People are at present *NOT* told about
> the importance of promoting groups, on the contrary, they are
> actively discouraged.
During the CFV period yes soliciting Yes votes is discouraged and may
result in a canceled vote, however proponents are permitted and
encouraged to advise and promote the proposal during the RFD phase to
those that might be interested in using the proposed group.
Even during the CFV stage advising users a vote is being conducted, by
both posting pointers to groups listed in the CFV and by use of a sig.
file. While neither should request a Yes vote, alerting posible users
of a vote is occuring is permitted. In general during the CFB stage
discussion about the group should be limited to non existant, becayse by
this time the proponent has finalized the proposal and discessed the
merits of having a new group.
Jon Bell
Markus Kuhn <n03W36...@cl.cam.ac.uk> wrote:
>
>Last time I made an RFD/CFV (misc.metric-system in Summer 2002),
>I was told by the UVV documentation that a proponent is expected
>to show some restraint in campaining.
That applies only during the voting period, after the CFV is posted. By
that time everyone who may be interested in the group should already be
aware of the proposal, via the RFD discussion and other efforts by the
proponent.
In other words, you may "campaign" all you like during the pre-RFD and RFD
phases, to drum up interest for the proposed group. During the vote
itself, you may remind people that the vote is now taking place, but that
is all. By that time you should have your supporters all lined up and
ready to go to the polls, so to speak.
ru.ig...@usask.ca
>>On 2 Sep 2003 07:54:04 -0700, mcc...@medieval.org (Todd Michel McComb)
>>wrote:
>>>Disappointing, perhaps, but it was a virtual certainty. The
>>>proponents were unwilling to seek voters.
>>
>>Were they unwilling or did they not know the importance of promoting the
>>groups? Were they told and refused to listen?
>Last time I made an RFD/CFV (misc.metric-system in Summer 2002),
>I was told by the UVV documentation that a proponent is expected
>to show some restraint in campaining. I did, and lost the vote due to
>a lack of participants. People are at present *NOT* told about
>the importance of promoting groups, on the contrary, they are
>actively discouraged.
That is only half true. You were probably told to show restraint
during the vote. However, early during the RFD I told you in
Message-ID: <ai9ven$713$1...@tribune.usask.ca>
"Again, I stress that your readership has to know about this
proposal right around now, not at voting time, now. You can't
pop up a CFV and expect votes to come in. Advertising the
proposal during the vote has some restrictions, and the leadtime to
response can be long, so advertising has to start now, if you
haven't started already."
ru
--
My standard proposals rant:
Quality, usefulness, merit, or non-newsgroups popularity of a topic
is more or less irrelevant in creating a new Big-8 newsgroup.
Usenet popularity is the primary consideration.
Todd Michel McComb
BarB <pat...@earthlink.net> wrote:
>Were they unwilling or did they not know the importance of promoting
>the groups? Were they told and refused to listen?
Before even posting the RFDs, we told them very specifically that
if they could not find other newsgroups into which to post the
proposals, they would be very hard-pressed to find voters. The
proponents said it wouldn't matter, that they had plenty of votes.
Todd McComb
mcc...@medieval.org