I love the fact that RubyForge is available for us. It’s one resource that almost every Ruby developer working on free software is bound to need. One thing that I don’t like is how we pull in the GForge juggernaut for projects that often consist of one or two files.
If you look around RubyForge, you’ll notice that many projects have 10 tabs on their project page: Summary, Forums, Tracker, Lists, Tasks, Docs, Surveys, News, SCM and Files. While in theory this is a great idea, it’s rare for a developer to want to use GForge for all 10 of those things. Today I finally decided to poke through the admin interface and find the “Public Information” section. All of these things can easily be hidden.
As I poke around RubyForge, I do see I might be a little late to the cleanup party. The Rails project on rubyforge is blissfully barren, and many other popular libraries have done this as well. But as a word to those who are still showing ten tabs and using two, tweak your UI. It’s better to have a user email you and ask you where your mailing list is than it is for them to post on a forum that you never knew existed and not get an answer.
Just hoping to bring a little zen to RubyForge, and to never see this message again:
“This project has no visible documents”
"It's better to have a user email you and ask you where your mailing list is than it is for them to post on a forum that you never knew existed and not get an answer."
I made a suggestion, a while back, that project admins should have to opt out, not opt in, as far as getting emails for tracker/forum/list postings. That's one of the biggest gotchas for people new to RubyForge.
I really wonder how hard it would be to redo RubyForge with, say, Rails.
- Dan
I made a suggestion, a while back, that project admins should have to opt out, not opt in, as far as getting emails for tracker/forum/list postings. That's one of the biggest gotchas for people new to RubyForge.
Either this or have them disabled by default. It seems like many projects do not use these things, so having them 'one click' to add them in and be aware of them wouldn't be unreasonable. I'd be happy with either solution, though.
I really wonder how hard it would be to redo RubyForge with, say, Rails.
Starting with Collaboa(http://collaboa.org/about) as base and customizing, I imagine it wouldn't be terrible.
YAY! totally agree! Also? Turn off anonymous bug reports! HUGE difference being able to contact someone for more info!
So true, well said indeed! There's even a FAQ entry in that talks about that... the more unused stuff you can turn off, the cleaner the project is. There are some useful tips for keeping the mailing lists clean, too, here.
Thanks for posting this thought; it'd be great if folks see this and uncheck some boxes.