-
Notifications
You must be signed in to change notification settings - Fork 0
Codingparty howto
It's a traditional gathering of coders around a common purpose related to a free software project. There is a location, a given time, a topic, and a focus on sharing tips and tricks, learning by doing, and contributing to the free software community.
A coding party is a gathering between several computer geeks to achieve collaboratively a common mission. This goal is arbitrarily chosen as a pretext to share knowledge, explore unknown technologies, experiment way to do things that they otherwise don't have much occasion to test in their work context. As such event follows a long (at computer age scale) history, there are usages and practices that are recurrent in those meetings. This file lists a selected set of parameters that a coding party organizer or participant should take in account (and freely adapt to the context).
From experience on past events, some fixed parameters are recurrent and dealing with them should be a priority. Those are general description of components of the recipe of optimal fun.
The party begin at a given time and its duration is defined. Well the thing is sometimes duration can extend, especially in the night, and such extension should be expected if the momentum is appropriate. The topic has to fit in the time pattern, usually one day is a good scale, but it can be few days or one week for more ambitious projects.
Some real world facility needs to be available according to the number of participants. Of course the facility has to fit some criterias depending on the topic of the party. Usual asset includes a
- non-public space, where the activity can be focused and dedicated
- decent internet connection and local lan set up
- enough empty tables, wires, power cords and multipliers (if not, they need to be gathered by the organizer)
- easy access to beverages (preferably coffee) and food (proximity to some food supplier at the corner of the street is enough)
- any optional device empowering on-site collaboration : white board, paper board, beamer, large screen
- access to whatever asset according to the topic of the party (if party involves electronics, some tools)
Usually the location manager provides the access to the facility as a sponsoring feature. Sometimes a deal is made with the organizer to cover some fees with help of other sponsors. But access to the party has to be free for the participants, that's the responsibility of the organizer to find a way to avoid money consideration. Geeks just bring their brains and enthusiasm, the rest is already managed. In best cases, the food and beverage are also for free, included in the sponsoring.
A clearly defined topic should help participants to focus on a common goal. The choice of that topic is the responsibility of the organizer, sometimes one plays the role of the author to give the seed of the topic and the rest is done collaboratively. From that topic a roadmap will be self-organized, hopefully, at the beginning of the party. There is no real rule about how to do that, it can be very organic, sometimes quite messy, it does not matter as far as all participants feel comfortable with the way it's conducted.
Many times the topic includes using some technology new to the participants, in that case if someone is more familiar with it than the others, the party can begin with a presentation. As well, if the topic is leaded by an author, he can take time to explain his vision, try to reach an agreement with the participants, maybe negotiate his vision with the mood of everybody if the size of the group permits it.
For handling the collaborative coding, some setup has to be decided and prepared before it begins. This includes most of the tools that free software community uses for long term projects, like :
- a source management system for hosting the produced source code, possibly on a public space like github.com
- some wiki space or text editing central point where everybody can keep track of what they are doing and what they are finding
- an shared space to share files, like photos that are taken during the party as soon as they are taken
- some synchronous discussion space, like an irc channel, logged by some bot, where people can copy-paste links, talk with the keyboard (yes yes, even when 2 meters away, irc is still useful), broadcast ideas or references.
- sometimes a mailing list can also be a good tool, but for one-day parties that may be overkill
- some recording device, including digital cameras and video cameras to capture and document de development process, give some feeling about the event. If there is any presentation, it can be recorded on video and published as well.
The recipe for maximum fun includes the evidence to everybody that this activity serves several goals in one move. Obvious goals can include :
- contributing a decent solution, result of a group effort, to the free software community for common use
- learning-by-using some new version of some software, library, method, setup, concept, and this knowledge can have an effective impact on each participant potential
- sharing tips, techniques, configuration files, tricks, among developers or craftsmen, for self productivity improvement
- scratching personal itch, in some cases, when the topic fits some solution that one can actually really use in his daily life
- extending personal network, meeting new people, especially for geeks that are not usually the very social kind, is very valuable
- perpetuating the hackers culture, fundamental principle that makes the free software community pertinent, vibrant and innovative, without top-down control
- improving the agility of team-working in non-centralized way, and by that way improving the self confidence for contributing to more open source projects
Even if organization of coding party is more fun when organically self-organized, there are some roles that are clear and that need to be fulfilled, giving occasion to everyone to find his place in the fun. Here is a non-exhaustive list of roles that we can think about:
- a sponsor host, he provides the facility, the internet network, and other assets linked to the facility
- other sponsors, if necessary to cover the fees on beverage and food. That is not strictly necessary but actually it can open opportunity for some business deals. For example, if the host is an institution or a company that has a need that could be addressed by a free software solution, they may be happy to fund an event that helps them create the solution that they can use afterwards. In such case, they can agree to the topic, and they can somehow influence the context, at the proportion of their generosity. For example if sponsor pays plane tickets to organize an international event in a foreign country, participants are more likely to be tolerant on the intervention of that sponsor in the choice of the topic. But the role of the sponsor has to remain limited in the running of the event. Coding parties don't substitute to real-world business development cycles.
- an organizer, that manages to gather all required components of the event for it to happen, finds sponsors, deals with the host, helps in explaining to participants how things are going to happen, and to work on the transparency for everyone to have a clear view of what are they doing here.
- an author, when the topic is related to an idea that someone had and that others are willing to help developing for the common good.
- one or many reporters, that take pictures, write blog posts, take videos, publish content, tweets, social network seeds, about the event. That role is usually chosen by people that don't feel confident for participating in hard core coding but still want to help making it fun and memorable. The visibility on the event has many advantages, for the participant but also for the community at large, as a demonstration of free software liveliness.
- coders and makers, graphic designers, scripters, sysadmins, etc ... well, of course, for doing the real thing, those are most of the participants hopefully.
Usually, don't plan to do anything after the event. There is a special ambiance during the event that motivates that things are done. By experience I know that everything we plan to do after the event is not done. It can be sorting the photos, writing documentation, cleaning some code. If it's not done during the party, it will not be done (unless rare exceptions). So, publishing content, sorting out things, has to be part of the roadmap in-party. Of course the outcome of the party will eventually produce real usable code that will have a life after the party. We are talking here more about the event related activities and content.
Alcoholic beverages do no good with coding, they are for another kind of party that can be the real after-coding-party maybe, but it kills the focus when abused while coding (ok, well, one beer won't kill, just don't fill the fridge with it). There is sometimes an exception for German coders, which have a special stamina, though, but better limit those cases.
Sometimes one participants decides that he knows better and kills the ambiance by deciding for others what to do and who does what. It's totally not welcome in that context. It's kind of hard to control the control freaks. The best I know for that is to use humour to disable their instinct. At worse they get pissed off and get away. At best they fear the sarcasms and tune it down. It may depend the general maturity level of other participants too (seasoned coders know very well how to ignore that kind of beats).
Participants have to feel no pressure, except the one they chose to put on themselves by choice. That way they do what they really want to, and they do it with heart. If there is too much strict objective it may fail, or feel like a job, spoil the fun and kill the motivation. If the coding objective fails, it does not matter that much, the purpose is multiple and the sharing and the learning will have succeeded.