Railoids:
This group has kind’a high traffic. That makes ignoring the group
hard, but more importantly it makes having a conversation hard.
(Modern Web2.0 interfaces notwithstanding!) Given the glacial pace of
Brand X Web D., this situation ought to get much worse long
before it ever gets better.
Should we split out three splinter groups? We should name them, oh, I
dunno, how about…
rails-model
rails-view
rails-controller
?
–
Phlip
http://c2.com/cgi/wiki?ZeekLand ← NOT a blog!!
Phlip wrote:
Railoids:
This group has kind’a high traffic. That makes ignoring the group
hard, but more importantly it makes having a conversation hard.
(Modern Web2.0 interfaces notwithstanding!) Given the glacial pace of
Brand X Web D., this situation ought to get much worse long
before it ever gets better.Should we split out three splinter groups? We should name them, oh, I
dunno, how about…rails-model
rails-view
rails-controller
How about not splitting the group, but creating the three new ones ?
Some problems cover all three bases, and some questioners wouldn’t
necessarily know which list to post to in the beginning ?
My 2c
Alan
On 12/7/06, Phlip [email protected] wrote:
This group has kind’a high traffic. That makes ignoring the group
hard
How so? Can you not figure out how to unsubscribe? It’s a Google
group so you can read it online without actualy being a member. In
addition you’re using GMail so you have labels and filters at your
dispose.
but more importantly it makes having a conversation hard.
Again you are using GMail, have you not discovered the ‘star’
meachanism?
(Modern Web2.0 interfaces notwithstanding!) Given the glacial pace of
Brand X Web D., this situation ought to get much worse long
before it ever gets better.
What does that even mean?
Should we split out three splinter groups?
No. Scan the subject lines and ignore the messages you do not wish to
read. Use your mail filters.
–
Greg D.
http://destiney.com/
On 12/7/06, Alan F. [email protected] wrote:
Should we split out three splinter groups? We should name them, oh, I
dunno, how about…rails-model
rails-view
rails-controllerHow about not splitting the group, but creating the three new ones ?
Hoo-ya. Specifically, splitting a group is impossible. Look at
news:comp.lang.java . The root group isn’t supposed to exist anymore.
Or something like that…
And I didn’t mean I would ignore the three groups, I meant that I
would enfolder them, then bulk-delete them more safely than I
currently bulk-delete the home group.
Online forums work when regulars migrate to the systems they know
best, so my suggestion, in theory, would improve the responses.
–
Phlip
http://c2.com/cgi/wiki?ZeekLand ← NOT a blog!!
I agree with the other sentiments (that we should NOT split this group
or create new ones) with one small exception: I wouldn’t mind having a
separate rubyonrails-announce list for announcing new Rails sites.
How about dividing it into questions vs. announcements (of any type).
Many solutions involve some unforeseen combination of view, model,
controller.
Also, I just joined the Ruby on Rails: Talk google group and my posting
there showed up here. Is there a recommended way to post to avoid
duplicates?
Shauna
i second (third? eighth?) the idea of having a separate
announcements list. it’s also the sort of thing that lends itself to
digests in a way that the main list doesn’t.
i’d contemplated the idea of a newbies list, but i can’t see a
practical way to do that.
-faisal
i second (third? eighth?) the idea of having a separate
announcements list. it’s also the sort of thing that lends itself to
digests in a way that the main list doesn’t.i’d contemplated the idea of a newbies list, but i can’t see a
practical way to do that.
There isn’t 
This has come up on every list I’ve ever been on
(freebsd,
php, postgresql, mysql, etc.) and the consensus is that you can’t do it.
Newbies won’t post to the newbies list cause well, they want their
question answered by a non-newbie. So what happens is everyone reads
and
posts to both lists.
Just look at how many very rails specific questions end up in the ruby
list… and that’s not even a list for newbies…
-philip
Thomas, Mark - BLS CTR wrote:
I agree with the other sentiments (that we should NOT split this group
or create new ones) with one small exception: I wouldn’t mind having a
separate rubyonrails-announce list for announcing new Rails sites.
But what’s the best book about Rails?
–
Phlip
http://c2.com/cgi/wiki?ZeekLand ← NOT a blog!!
Faisal N Jawdat wrote:
i second (third? eighth?) the idea of having a separate
announcements list. it’s also the sort of thing that lends itself to
digests in a way that the main list doesn’t.
How about an announcements blog?
Don’t hit don’t hit!!
i’d contemplated the idea of a newbies list, but i can’t see a
practical way to do that.
The solution to the newb problem is to leave the base list to them.
They are newbs, it’s the first list they will discover, graduate newbs
will help fresher newbs, etc…
–
Phlip
http://c2.com/cgi/wiki?ZeekLand ← NOT a blog!!
Philip H. wrote:
There isn’t
This has come up on every list I’ve ever been on (freebsd,
php, postgresql, mysql, etc.) and the consensus is that you can’t do it.
Newbies won’t post to the newbies list cause well, they want their
question answered by a non-newbie. So what happens is everyone reads and
posts to both lists.Just look at how many very rails specific questions end up in the ruby
list… and that’s not even a list for newbies…
If the XP mailing list had not splintered into everything from
agile-testing to refactoring, then the XP list would be stuffed full
and useless. It’s not about the newbs, it’s about the volume. If you
take care of the volume then the newb problem, among others, will look
smaller.
When a group grows too large it naturally splits.
–
Phlip
http://c2.com/cgi/wiki?ZeekLand ← NOT a blog!!
The XP list was easy to split because (1) virtually everyone on it was
fairly advanced technically and knew where the dividing lines between
subtopics were and (2) the topic is very splittable, and (3) software
development methodology attracts the sort of people who like to obsess
over taxonomies.
With Rails (and Java and PHP and Perl before it), there are subtopics
that merit lists of their own, plugins, installation, announcements and
deployment, for instance. Unfortunately, most questions fall into a
more general bucket of Making Code Work, and many, many questions
involve a controller and a view, or a model and a controller, or a
controller and something in config/*, or AR associations, two plugins
and a partial, or the order in which javascript and css files need to
be loaded… In short, they’re Rails Questions, and I think splitting
off announcements, plugins, installation and deployment into their own
lists will still leave the main, unsplittable part of the list with 90%
of the volume it already has. YMMV.
or create new ones) with one small exception: I wouldn’t mind having a
separate rubyonrails-announce list for announcing new Rails sites.
No need for a separate list: in GMail, I created a filter for
subject=’[Rails] [ANN]’
, and voilà , a Rails announcement list.
The same trick can be reused to separate newbies’ post:
subject = [Rails] AND ((newbie) OR (noob))
, or Rails jobs, or Rails meetings, etc…
Alain
Faisal N Jawdat wrote:
i second (third? eighth?) the idea of having a separate
announcements list. it’s also the sort of thing that lends itself to
digests in a way that the main list doesn’t.
Why not just stick with the current practice of people putting [ANN] in
the subject line at the beginning? That way, it can be easily filtered
off.
i’d contemplated the idea of a newbies list, but i can’t see a
practical way to do that.-faisal
I think a separate newbie group is a bad idea… this has been discussed
many times in this group
Cheers
Mohit.
hatless wrote:
of the volume it already has. YMMV.
No worries. I have since decided to go with the Crackberry, voice
synthesizer, and bluetooth molar filling.
–
Phlip
http://c2.com/cgi/wiki?ZeekLand ← NOT a blog!!
How about separating out issues to do with Rails connections,
configuration, and deployment into a separate forum? Those issues don’t
seem to overlap much with coding or data structure questions. Kind of an
internal vs. interface division.
Even if someone comes first to the general Ruby on Rails forum, they
could be directed to the Rails Interface forum (or whatever) when
someone answers.
Shauna
I second this one…I think a rails deployment/config list is really
needed.
On 12/15/06, Shauna [email protected] wrote:
Shauna
–
Posted via http://www.ruby-forum.com/.
–
seth at subimage interactive
http://www.subimage.com/sublog/
Please no new list, splitting list etc. I want to have newbie
questions, ANN etc. Gmail, Yahoo mail or any other mail client can do
filtering … and newbies are good its a good input to book writers,
coders, rails core team etc, too see what types of problem the new
user having.
IHMO the reason given i.e. high traffic and other comments for
splitting the group is not convincing.
Regards
But what’s the best book about Rails?
I’ve only been on Rails for a few months, but here’s (briefly) how I
look at it:
Agile Web D. was my starter. I liked it a lot, but got
bogged down in their detailed example.
Ruby For Rails was my second book, and I liked it more than Agile
because it dealt more with techniques without getting bogged down in a
big example. But maybe I could enjoy it more because I then had the
benefit of some Agile.
Beginning Ruby on Rails for E-Commerce is my current favorite because
it goes step-by-step through Test-Driven-Development and lots more than
I think (based on previous software development experience) is the
ideal way to go.
Rails Recipes is something else I picked up recently because its got
succint answers to a lot of interesting (to me, at least) How-do-I
questions.
Of course, it’s also important to have good Ruby support in the
background. I’ve got:
HTH,
Richard
Zaheed Haque wrote:
IHMO the reason given i.e. high traffic and other comments for
splitting the group is not convincing.
Then why other groups split?
–
Phlip
Redirecting... ← NOT a blog!!!
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs