The HSV.rb lunch what-to-do meeting (2009-05-19)

[Ryan Waldron]

[Warning: This is long. I didn't have time to write a shorter version.  Plus, we talked about a lot of stuff in a short period.]

We had a great lunch at Jason's (love those muffins!) on Tuesday the 19th.  Pardon me if I misspell any names, but Preston, Taylor, Daniel, Bryan, and me were there.

I'll skip, for brevity, the interesting Erlang and Jabber discussions.  You never know what you might miss if you don't come to lunch.

I sort of repeated what I'd said in my initial email about all of this.

== Project Consensus and Tracking Tool ==

Daniel suggested as a possible first app a sort of project consensus tool:a web site where people could post project ideas, and then HSVrb-ers could vote them up and down, perhaps prioritize them by vote.

We kicked that around a bit.  It could allow for comment threads, attachments, pictures of mockups or site ideas, etc.  There may already be something cool like this that we could use, but if there's not, Daniel's got a good point that we *need* something like this to keep up with all our other somethings.

== Commercialization ==

Preston (I believe) brought up the commercialization. We talked about open-source and business uss in general.  The consensus seemed to be, "If you can build a business out of something we write without interfering with the project itself (like trying to claim ownership or whatever), have at it."

My personal take is similar to the FSF's: if you can sell Emacs, sell Emacs.  But you can't force me to buy it, or keep me from building my own from the same source.

== Bad Code, or Putting It Out There ==

Don't remember how this came up, but someone (Preston?) mentioned they had a project they'd be willing to open-source, except it was "really ugly" and he'd have to clean it up first.

This is a big problem, though. Most of us seem to have this fear that by releasing some code that's not beautiful and elegant, they'll be forever branded incompetent. I don't think this is the case at all, but we have to work on overcoming it for ourselves and for everyone else.  If we're talking about working on code as a group, everyone in the group is going to see code that we do, and some of it is going to be ugly.  Some if it SHOULD be ugly; if you're always writing beautiful code, you're likely not exploring any new areas and challenging yourself to do stuff you haven't done before.

I think somewhere down inside each of us, we want people to think that we're smarter than we are, and that we write better code than we do.  Perhaps it's just me. :)  But the thing is, there's always a reticence to 'open the kimono' and let strangers take a look at what we've written.  For a few people this doesn't seem hard (but more likely they've just worked hard to overcome it), but I know a LOT of people who've said basically this same thing.  You can browse mailing lists and IRC logs and find an almost constant refrain of "Well, I've got something like that 90% done, but I'd have to clean it up a lot for anyone to see it."

The problem is two-fold: 1) One of the main benefits to opening up code is that OTHER PEOPLE will help you clean it up, and 2) if you've got code that does Task X, and there isn't any *other* open-source code that does it, your code by default is the BEST AVAILABLE code for Task X, and people need to just shut up if they don't like it.

== Other Project Idea Sources ==

One idea for a source for projects to do is forking existing projects and fixing them or modifying them or adding to them or transforming them into something else.

Someone mentioned acts_as_twitter as a possibility.

We also talked about just targeting some project or gem and trying to pick out some bugs, fix them together, and submit patches and try to get them approved.

It's perfectly legitimate to cruise around on RubyForge or Github and find candidates that need fixing or extending and suggest/advocate them to the group as a group project.

And while we're at it, the *entire* group doesn't have to be working on the same thing.  We just need to have enough people looking at common code to (1) make bugs shallower, and (2) have pre-existing context to be able to help each other out and cooperate on learning more Ruby.

== Social Networks and Web Presence ==

We agreed we should create an hsvrb account at github (Done!) and at Twitter (done!)  I've created both of these for us to use as soon as we figure out what we're going to use them for (see below).

Bryan mentioned the hsvrb.com domain, and we talked about what should go there.  I think the initial view was we should start out with a Wiki to get some collaboration going and figure out what sort of things people would like to see living there.  My guess is that we'll eventually have some sort of more full-featured CMS there, with Wiki and other stuff as part of it.

Someone suggested it would be cool to do a githubAPI integration such that activity in the hsvrb@github acct would show up automatically on the site.

There was a brief discussion of whether there were any good Ruby or Rails Wikis and/or CMS packages we could use.  Bryan had to leave, but he asked that if people had a suggestion for a good one to let him know and he'd put one up.

==============
So if you have a suggestion for a good Ruby or Rails Wiki and/or CMS -- email it to the hsvrb group and let's look at it!
==============

We talked for a bit about how to use an hsvrb@twitter account.  We talked about having messages retweeted automatically under certain conditions.  One example would be that people could register as @hsvrb members, then DMs from their twitter accounts to @hsvrb would be retweeted by @hsvrb, so we could get a sort of tweet-blast system set up like that.

o I have on my notes 'Switchvox devel', but I have no idea what that was.  Probably I had an idea (and it was probably actually for Asterisk) but forgot it before I could expand it further.

As for content for hsvrb.com, there were a lot of good suggestions, including sets of links and resources that other people used that we could share, a Wiki for collaborative information, a set of best practices (really more people explaining how they'd figured out how to do things that worked for them, not RMM).

I suggested we really needed to figure out how to be more n00b-friendly, and encourage people who are interested in Ruby but don't know about it, or who are just dabbling in it but aren't sure, to get involved and come to meetings.  Preston pointed out that we needed to get the word out better about HSV.rb's existence, to tell people we were here.

So that led to more discussion about site content for hsvrb.com, including a "who we are" sort of statement of purpose, some encouragement to any and all to just come by, some project examples of stuff we were working on or had worked on in the past.

Someone also mentioned a place on the site to submit questions, which I thought was an interesting thing.  Obviously, there's some overlap here with the mailing list, and we wouldn't want to fragment the group's discussion effort.  This is traditionally a difficult problem, because some people for some reason prefer web forums to email lists, while others (like me) much prefer email lists.  And it's hard to find a way to satisfy both groups, though some places use a Google Groups-like method of having the email list and forum basically be two views of the same data model.

We also discussed having meetings and get-togethers be more short-talk and demo-oriented, with a default to just hacking on projects.  If someone wanted to do a 45-minute presentation, we're happy for that to happen, but if not, then if people want to do 5-10 minute "lightning talks", that's great, or if nobody has anything to present, we'll pick up one of the existing projects and start hacking on it.

We didn't get far enough to really talk about nuts and bolts of how 8 people in a room hack on a single project, but we'll get to that, I'm sure, at a later luncheon.  We also talked about pairing, and I reiterated my desire to go hang out and code with people, beginners or not, on any project at all.  I'm going to keep doing this until someone takes me up on it. :)