Re-post: [Mailing list -> ruby-forum.com broken?]

Eric H. wrote:

This is kind of a problem, because people are getting answers to
And I’ve seen forum replies come without context, or under a different
name, or in a new thread. This makes answering them very difficult.

And I’ve seen emails on the mailing list with the same problems. I don’t
think cutting off that part of the Ruby community is the solution. I’m
more in favor of some of the other suggestions, such as an explicit
statement about how the forum is a mailing list gateway (although it
is on the main page, right under the forum name), maybe a posting of
the newsgroup FAQ, and requiring people to create an account.
Personally, I use the mailing list most of the time, but different
people have different preferences.

Just my opinion.

-Justin

Nathan O. [email protected] writes:

I think I see a little class separation going on here. I’m a newbie to
Ruby. I’m not incompetent, but I do often ask question that “could be
answered with a 3 second Google search”… if I only knew what on earth
I was searching for. It may be obvious to one person, but otherworldly
to someone who’s just encountering a gotcha for the first time.

I’ve really loved ruby-forum.com since I started using it. People are
VERY friendly, understanding, patient, and have all the answers to all
my questions. Excellent community, excellent dialog.

How about just requiring users to register before they can post to
ruby-talk? AFAICS, everyone can post ahead right now.

On 5/3/06, Christian N. [email protected] wrote:

my questions. Excellent community, excellent dialog.

How about just requiring users to register before they can post to
ruby-talk? AFAICS, everyone can post ahead right now.

Yep, including guests, which leads to this nonsense:
http://www.ruby-forum.com/topic/63894#70349

Christian N. wrote:

How about just requiring users to register before they can post to
ruby-talk? AFAICS, everyone can post ahead right now.

I like this idea.

On May 3, 2006, at 1:03 PM, Nathan O. wrote:

this is cross-posted to a mailing list.

Is it really detrimental?

I don’t believe anyone gets paid to respond to ruby-talk so increase
in noise makes it much more likely that mails will be ignored.

I think I see a little class separation going on here. I’m a newbie to
Ruby. I’m not incompetent, but I do often ask question that “could be
answered with a 3 second Google search”… if I only knew what on
earth
I was searching for. It may be obvious to one person, but otherworldly
to someone who’s just encountering a gotcha for the first time.

Subscribing to a mailing list takes work and causes you to get mail
you might otherwise not want. Posting on ruby-forum takes much less
effort, you don’t need to log in and it won’t clog up your inbox.
The difference between the two causes people who go the mailing list
route to do a more exhaustive search.


Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

I do not believe web based interface makes the level of discussion low.
Take comp.lang.c++.modreated and comp.programming.threads as
examples. Two of them are filled with discussion of
detailed/professional
discussion on C++ and concurrency, respectively. However, both of
them are exposed to the public via groups.google.com.

The quality of comp.lang.c++.moderated is maintained by moderators
who examine all the messages and approves them only if they are not
too novice questions. Sometimes, a moderator directly answer to the
question via email before they filter the message. This can be done
because there are many other places where novice can ask anything.
Such atmosphere of them are maintained not because of the absence
of web-based interface, but because of process.

This is the list which is just named ruby-talk. It’s not named like
‘ruby-master’
or something like that. Not having web based interface does not
guarantee
the
quality of discussion, I believe. Why don’t you let people access all
the
messages
in the mailing list? Why should we have to raise the bar to newbies
(which includes me) anyway?

Actually, I’ve joined mailing list when I’ve found out that ruby-forum
does
not work
(I know it runs well right now), but I found not too much difference in
this
list.
People in comp.lang.ruby are discussing some ruby questions on APIs,
bugs,
how-to. Messages in this is not radically different from them.

I mean, what is quality anyway? I believe it might be something too
subjective.

Sincerely,
Minkoo S.

Andreas S. wrote:

Funny enough, you didn’t care notifying me about the problem, as did
nobody else. The gateway would have been up again in no time.

Andreas: I didn’t mean to irk you with my behaviour. Rest assured
you’ll hear from me quickly if anything like this ever happens again.
:wink:

Christian N. wrote:

How about just requiring users to register before they can post to
ruby-talk? AFAICS, everyone can post ahead right now.

Sounds good to me.


I’m all for keeping low-quality posts out of ruby-talk. I wouldn’t want
to be in the judgement seat deciding which are good or bad, though.
Personally, I would rather not see the forum mirror for ruby-talk
disappear. I have always preferred forums over mailing lists and
newsgroups (though my stance has softened lately with the advent of
GMail which displays threads rather nicely).

I’ve been on more than a few forums in my life, and the fact is (based
on my experience) postings are not really bad just because they’re done
on a forum versus a mailing list. There are juvenile forums, and there
are top-notch forums.

My opinion is that we should just keep putting in little strictures and
making little adjustments until we get to some reasonable state of
affairs. Requiring forum registration to post to ruby-talk would be a
good start, I think.

Who knows, maybe we could also have moderation for ruby-forum, to act as
a bit of a pre-ruby-talk sieve.

Some extra warning text about the mirror-ness might help, too.

Pistos

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs