Some Camp KDE reflections
Unfortunately yesterday was my last day out at Camp KDE. Vacation is sparse for me right now after blowing it all over the holidays and on the wedding and GCDS/Akademy. So real life calls…
I neglected to post my slides in my day 1 review so here they are. In case you didn’t know from the Dot article my talk was about simple and practical ways to get involved in KDE. The idea was that even if you don’t know much about writing code (like me) you can still be a contributor in our community. I provided information on different areas that people can get started in and then listed the web sites to go to or people to contact to get up and running. Getting people besides developers to help in these areas is critical. It allows developers to focus on what they do best, writing code, rather than triaging bugs, writing documentation, doing user support, and so on. As great as our developer community is we can’t expect you to do everything all by yourself, and this opens up a whole new world of opportunity for users to become contributors. So if you’re a user, please have a look and see what you can do to help. If you’re a developer, take a look as well as it’s a great resource to get your non-developer friends involved in KDE projects with you.
Switching gears a bit…as someone who has taken an interest in the promotional side of KDE one of the things I’ve been trying to do lately is identify things we do well and things we can improve on with regards to hosting or participating in meetings, conferences, sprints, etc. To this point I’ve been to Akademy once, the 4.0 release event, a promo sprint and now Camp KDE. I’ve also got a pretty large array of professional conferences under my belt from my day job so there’s plenty I could compare us to. Overall I think we tend to do pretty well in hosting these things but of course there is always room for improvement. While it’s fresh in my head I wanted to touch on some things that stood out to me:
- Information organization and distribution
- The links which gave directions to the venue were sort of hidden in the Camp KDE web site. Looks like it’s probably a stylesheet related issue but the links didn’t stand out at all on the page which made it tough to easily find the directions (just a detail, but I think an important one)
- Signs or even having some organizers hanging out near the exteriors of the building directing people to the right place would also be a nice touch next go-round. UCSD seems to be an especially confusing campus…but in general anything we can do to make it easier on people to find the right building and right room can only be a good thing.
- Conference content is scattered. There are so many valuable things being created at the meeting…we’re video recording all the presentations, people mostly had slides for their talks, lots of people were taking photos. All of that is great! But to make it even better I think next time we should try to setup a section on the conference web site before the meeting that could serve as a portal for aggregating all of these things so that people don’t have to search all the Planet KDE posts, Dot posts, identi.ca feeds, etc to track all of this down.
- Logistics and event execution
- It’s always hard to find the best of all worlds for lodging (usually balancing cost + convenience is the tough part). But the hostel was not too close to the meeting location and also seems to have gotten mixed reviews in terms of the quality of the rooms, etc. This is especially difficult in the United States because hostels are just not a part of our culture and therefore are often run down or in sketchy geographic areas. In the future I think we should continue to look for alternative ideas to help ensure it’s easy for people to get to the event, but also be cost effective. I don’t have a better solution readily available and believe that our organizers made the best of the options they had…I’m just saying I think we should continue to strive to improve on this in future events held in the US.
- Perhaps this will change as the students return to class from the holiday weekend, but it seemed that we had a fair number of people register that did not show up the first two days. This one is tricky to resolve. We don’t want to discourage interested people from coming because they can’t afford a registration fee or something, but at the same time it’s hard to plan properly to accommodate a group when you don’t know how many are really coming. I know that personally I drastically began to cut back on efforts to recruit more attendees when we had 90+ registrants and found out the room capacity was 100 people. I think if we’d had a better grasp of the situation with no-shows we could’ve continued promotion efforts a bit further. I’m tempted to suggest that a small registration fee might make sense to ensure people who register are likely to actually show up. This fee could be used to provide people with swag (shirts, etc) or cover snack/drink costs. So it could be extremely cheap, yet still somewhat effective at ensuring only serious people register. Maybe $10-25 or something for the whole event?
- For setting up the order of the talks, I think we should put keynotes in the afternoon in case people show up late. In particular with Frank’s talk we had to delay the start of things quite a bit because of transportation issues with getting attendees to the meeting on time. While that is unfortunate no matter what, I think it would be better to have regular talks scheduled at the beginning and end of the day and to situate the keynotes in the middle (probably right before lunch rather than right after) when it’s most likely that the most people would be at the event.
All of this said, I’d especially like to emphasize that most of this is relatively minor and only geared towards trying to continually improve future events. I think Jeff has done a tremendous job at spearheading the organization of Camp KDE this year, along with all of the great help from the rest of the Camp KDE organizers including some fantastic local support from Andrew at UCSD. I’m very much looking forward to hearing about all the things you do the rest of the week and hope that you don’t get too waterlogged with all the rain you’re getting out there!
First of all, thanks for writing up your thoughts.
As one of the otherwise unaffiliated students who came because of the on-campus promotion and lack of a registration fee, I do support it being free to attend. I have been really impressed and awed by the folks I’ve had a chance to meet and listen to. Regarding the no-shows, I think rather than instituting a registration fee, it would be better to further clarify on the registration page that if you do register, you are expected to show up (because the venue space is limited), and add a space on the registration form to specify which days you can make it, if you can’t make it to all the days. Also, a registration *deposit* (maybe returnable in swag/t-shirts, or cash if requested) might be an option.
Thanks again for your talk, and to everyone for organizing the camp!
As for what you said in your talk, about opurtunities for non-technical participation — I think there are two main issues we need to improve on in this area: working with distros, and making a gentle learning curve. For the first point — KDE itself has very few end-users — nearly all of them come through distros of one sort or another. If we want contributors (technical or otherwise), we have to have the distros support to pass people through from their tools and systems (launchpad, cough, cough) to KDE’s. I think in many cases they would be glad to do this — but such discussions need to happen or the people just won’t get to KDE. Next, once we get non-technical people here, we need to facilitate getting them up to speed on how exactly they can help. The various classes and documentation we have are good, but more would be better — and specifically, identifying particular jobs (as you did in your talk), and working out exactly how a new person can get down to working on them would be great.
Your thoughts on the above would of course be appreciated.
Jesse, first, it was great meeting you in SD and we’re glad you could make it out to participate!
A deposit seems to me like another viable way to handle the no-show situation. That’s essentially what I was suggesting, but using the term “deposit” rather than “fee” is probably a better way to phrase it.
Making it clearer in our conference promotion efforts that we have limited space would probably also be beneficial as that would add an element of “hurry up before slots run out!” and also would let people know we expect them to show up if they register.
Regarding my talk there is one minor thing i want to clarify that might have been misunderstood. I think 95% of people that even run linux or KDE applications are “technical”. Non-technical people would generally not bother to replace their existing OS or find better replacements for existing apps. (exceptions being when a geek like us installs it for a friend or family member or something) However I think a significant proportion of our population are people such as IT professionals or computer savvy students that are very skilled with technology but do not necessarily know how (or like) to program. This is the crowd I am hoping to tap into as our next big group of new contributors.
That said, I think you’re right that lots of people will first identify with a distro before their desktop environment. There’s no question we should be cooperating with distro groups. But suppose you’re running a distro that comes with KDE by default and you decide you want to help out. What would you help with? Probably some application you use within the distribution right? Well pretty much everything you come in contact with when running a KDE based distro as a regular user is some KDE application.
Sure there are some exceptions as distros add their own tools or you may run some GTK based app like Firefox here and there, but I do think it’s quite easy to connect people to KDE directly.