[Vit-discuss] Getting Started [was Now, where were we?]
curt at hibbs.com
Sun Feb 20 05:16:43 EST 2005
Masayoshi Takahashi wrote:
> Yes, I'm here and read messages (thanks, Curt!). sorry too late response.
> We ruby-lang.org revise (or 'review'? I don't know an exactly word)
> team consist of Ruby user/hackers, not designers. So it's hard
> to suggest something in visual aspects, but we do them in
> functional aspects.
> I'm also in www-admin list. I guess the members in www-admin are
> too busy to maintain Ruby itself, so IMHO we don't have enough time
> and power to update web site. We need your help.
Excellent... it looks like we can form a very productive partnership!
Here is how I would like to see us to proceed. Let's take our charter from
* form a team to design the appearance
* form another team to choose the CMS
* create prototype on that CMS
The Visual Team
We need pick a core visual design team of no more than 3 people to design
the new ruby-lang.org site. These people should be actual producing
contributors, not mere commentators. This group would do the hard work of
the redesign in tight collaboration and periodically present their results
to the rest of us for feedback. This feedback would be considered
advisements which the core team would be free to accept or reject at their
This should give each of us influence over the final result while avoiding
the gridlock and committee-style blandness that often accompanies larger
In the meantime we should all post our ideas on what the new ruby-lany.org
should be (or should not be) as input to the soon-to-be-formed core team.
To help kick off this part, my choices for the core team are:
- Why the Lucky Stiff
- John Long
- Ben Giddings
What are yours?
The CMS Team
At the same time we need to select a team that will be responsible for
choosing the CMS that will power the new site. This team would research the
candidates, present their choice(s) to this group for feedback and,
ultimately, create a prototype installation with which the design team would
implement their design.
The same approach should apply here: no more than 3 people on the team who
are willing to be active contributors. Feedback from all of us would be
considered advisory, and the team retains the authority to make the
Here are my suggestions to kick off this part:
- Use Ruby based solutions.
Whatever capabilities the team decides to include (wiki, blog, etc.), I
think they should be written in Ruby. Its unlikely that there would be an
all-in-one Ruby solution, so this would mean the team may have to write some
glue code to tie the pieces together.
I don't have anyone to nominate for this team. I think that people who have
the time and interest to do this should volunteer. If we have too many
volunteers then we'll have to pick.
Feel free to disagree with the organizational outline I layed out above. But
be prepared to present concrete alternatives, because above all I want us to
get moving forward as soon as possible.
More information about the vit-discuss