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 Development, 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
?
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 Development, 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.
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.
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.
- Mark.
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?
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
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?
<a beat>
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...
Philip Hallstrom wrote:
There isn't
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.
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
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.
Phlip wrote:
hatless wrote:
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.
No worries. I have since decided to go with the Crackberry, voice synthesizer, and bluetooth molar filling.
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.
I second this one…I think a rails deployment/config list is really needed.
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 Development 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: - Programming Ruby (2nd ed.) - The Ruby Way (2nd ed.) - Ruby Cookbook
HTH, Richard
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
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?
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?
i.e. if the subject matter is self-contained lets say internationalization .. yes there is a need for creating such group and there is one AFAIK. There is already rails-dev etc, etc.
This a general list for i.e. catch all! you subscribe to it knowing so -- your choice -- the list is also searchable without subscription via google.
And speaking of High traffic I think its a good thing. Furthermore I would also say newbie questions are good thing! No newbie -- no new rails installation -- no book sale -- no consultancy services -- nobody is subscribing to the list -- dead end :=)
And we don't want that do we :=) Invite newbies with open arm cos its a good thing!!
Cheers
Zaheed Haque wrote:
And we don't want that do we :=) Invite newbies with open arm cos its a good thing!!
I only brought up the "newbie" issue, way up-thread, as an example. Answering newb questions is good for us (including mine!), because it shows where our documentation is lacking (including mine!!).
The question remains, why groups split? Why would news:comp.lang.java split into .misc. .programmer, .security, .advocacy, even the mindlessly technically incorrect news:comp.lang.java.javascript ?