gistfile1.textile

Composing this into a single tweet is impossible…

What I think we all want:

• A Rails Camp that is welcoming to newcomers and old hands alike; and
• A ticket process that is reasonably simple and does not require a large amount of time from organisers (they are volunteers!).

Either of these things alone is difficult, and combining both is clearly challenging.

As I’ve mentioned on Twitter already, there’s been some discussion about evolving the ballot process (mainly with regards to when CC details are collected, but expanding for groups is another option), and this could be an excellent project at this upcoming Rails Camp.

We need to keep in mind that complexity will add more headaches, and that the solution needs to be something the next organiser (Dylan in Brisbane) thinks would suit his plans.

And perhaps there are better ways to approach this: how can we make make someone’s first Rails Camp experiences less daunting? Should we look at a buddy system (clear in the ballot process)? We had a welcoming session on the Friday evening of the last camp to provide anyone who wanted the opportunity to meet others and hear about how they’re planning to make the most of the weekend – should this return for RC14?

Let’s be clear: saying something’s not ideal is okay, but offering solutions is much better :)

We had a welcoming session on the Friday evening of the last camp to provide anyone who wanted the opportunity to meet others and hear about how they’re planning to make the most of the weekend.

These are good :)

How about having two pools of tickets? One for people who haven't been (either at all, or to the last X Railscamps), and a general pool.

I'd say people who have been previously are the ones that are okay with FIFS, and if you wanted to cater for the people who can't be at a computer to buy tickets, you could have another pool for them?

Of course, this would then require checking that people entered the appropriate pool, but I don't think this would be a major issue.

Let’s be clear: saying something’s not ideal is okay, but offering solutions is much better :)

Agree. I think this is a case of "Talk is cheap. Show me the code." if you want it fixed, then try and fix it. That's how the volunteer world has to work.

Also personally I'm not a fan of my credit card details being collected when it might not be charged, but I understand that it's much easier to deal with from an organisation standpoint.

I agree, some kind of explicit meet-and-greet the Friday night is important, perhaps even with lightning talks: "My name is Ben and I want to work on X", for those that want to mention it.

At some previous camps, I know I only got excited about an idea and started work on it as a reaction to the lightning talks on the Sunday night.

Separately, I believe anything that induces more strangers to be introduced to each other earlier in the camp will improve it significantly.

Apart from that, though, I don't believe we need to work significantly to make the camp "less daunting". I think it's already a very friendly environment; it's normal for a first experience with a new group of people to be a bit daunting no matter what. But I realise I'm saying this as someone who isn't phased by that sort of thing (and has been to his far share of railscamps now); others' experiences might be different, that's just my take.

As an opinionated person (Rubyist, anyone?) who has not organised a Railscamp but has organised many other things, I can understand the "organisers need to be able to organise however they like because they're volunteers" argument, but I can't agree with it.

Organisers are volunteers. They've chosen to give up their free time to do something for the community. They've chosen stress, hassle and corralling a bunch of opinionated folk (Rubyists, anyone?). This is admirable. It should be supported.

So perhaps our efforts should be focused first on making that incredibly difficult task easier?

Defining and developing a ticketing process that works for our current needs can only help. The community has an opportunity to determine what makes a good ticket process for us now and to deliver it. Then the next organiser can simply use that, instead of having to come up with their own.

There are other tools organisers need as well. To my mind, volunteering to organise a Railscamp can mean volunteering to use the tools provided just as easily as it means doing everything for one's self.

I'm all for autonomy, but I fail to see the benefits in this situation.

Today's drama feels surreal. Feels like people are raging against a machine that doesn't exist.

RailsCamp is lo-fi, unstructured, self organising, a blank slate for attendees to fill in. Its not a professional event, nor is it professionally organised.

We're just people behind the scenes. In this case its pretty much just one person (as far as the ballot goes).

I love this community and this event particularly. I've worked hard to synthesise practical concerns, Ruby Australia initiatives, feedback and people's personal desires.

This year we've attracted a large number of new people through the scholarships. We managed to cover all the scholarship tickets with sponsorship.

Everyone who asked for a paid ticket got a ticket.

...

I'm a person, you're a person. Odds are we're going to get on. If you need something, ask me! If you want your mate or partner to come along too, ask me. Drop me a mail, ask me over margaritas.

This isn't a professional event (expectations may be too high.)

But due to the amount of work involved with RC organisation, I don't think I've done a great job of communicating things like this. I think if I could go back and redo it, I'd highlight it at the start (maybe through a Rails Camp manifesto, but at least with a bit more exposition on the signup page.)

layers

I feel that its important to keep the organisation of camp simple and unstructured. Then other initiatives (e.g. meet-n-greet, buddies) are layered on top by attendees.

Any tools or approaches should keep this in mind.

Lo-fi strikes a chord with me.

It'd be great to have tools, but they couldn't be mandatory. The way that a RailsCamp is run is set by the organiser and, to me that's an essential part of what makes it RailsCamp.

Despite all the stress it can cause, I really think this is important.

I chose to reuse the ballot site and code from RC13 for simplicity, but Dylan may not. He may loathe the ballot. He might like to do a treasure hunt for tickets. Its important that he has that latitude.

I think ballots are fine, and I think it went as well as it could have this year, all things considered.

I want to discourage block buying of tickets. This is not an attempt at regulating behaviour, but rather guiding the camp toward my vision for a RailsCamp.

I don't want to discourage couples or buddies, but I don't think it necessarily needs to be solved in code. For example, some folks just wrote in their preferences in the "dietary requirements" textarea. I love it!

new people

I think that the unstructured nature of Rails Camp can contribute to its initial daunting feel. In the context of this discussion, if you don't know the organisers beforehand, then they're obviously less approachable by default. We should work on this aspect for the future, while still maintaining the Rails Campi-ness.

In spite of this, I don't feel that we've had any trouble attracting new people this year, including a large number of women.