Conference ideas
Recaps of open-source conferences and other meetups in person.
It was the first year that FOSDEM had a open-source gamedev devroom on its schedule. Judging by the number of people appearing over the day, many people are interested in seeing what game development looks like in open-source.
Most talks were full (max secure capacity reached, people had to stay outside), which is great. Many projects work on their game very professionally, with positions and tools similar to those used in commercial gamedev.
We heard quite a few talks on different aspects of community management. One by wesnoth on how to balance a game, one about "things I wish I had known before joining open-source" and one on community management by the lead of the Exherbo linux distribution.
- Be friendly to every newcomer, no matter what.
- Never say "we don't need your help". This can scare people away from the open-source scene for years to come.
- Have a task for every newcomer. This can be achieved by opening tickets for very simple things like typos, style problems or very simple bugs. These tickets should not be worked on by the core team, instead they should be left available for necomers to work on.
- Make every contributor have their name on the commit/patch. Using git this is very simple, you can even reauthor commits that you do by yourself. This is useful to give credits to graphics artists/programmers who are not interested/are not able to setup git.
- Give credit for every tiny contribution if possible. wesnoth: "we have a simple rule for who can be in our credits: "If you ever contributed a single change to our project, you can be in the credits."
- Invest work into newcomers by helping them setup git and the project. If possible help them finish their first contribution, even if that means telling them every command they have to type into their console. Give them credit even if you basically did all the work. They just invested hours of work to get into your project, respect that. This will motivate them to do more work and they will eventually be able to contribute by themselves and will stick with the project.
- Say "thank you!" way more often than feels natural and necessary.
- We need someone responsible for balancing
Most (>90%) of the following is an excerpt of session notes from the 2011 GSoC Mentor Summit. More information on the Summit wiki (credentials required).
-
Use Wombat https://github.com/worldforge/wombat
-
public irc channel logs need to be accessible (information barrier)
-
implement irc bot "tell" functionality to send short irc user notifications (
!tell new-contributor a patch for the bug you reported was submitted, thanks a lot again!) -
it is possible to have a bot distribute news automatically to many social media sites: facebook, twitter, ..
-
every new developer that comes in the project should contribute their native language translations (at least the important modules, documentation might be of low importance)
-
encourage students to write personal blog, aggregate them to your project's planet / feed tracker software
-
create pamphlets / brochures people can download, print and post on boards, so they can do marketing for you
-
don't assign titles to people for PR and marketing, assign a "team" role, so it's always possible to add more people. Assigning one person only makes other feel they should not be stepping on others' toes
-
GUI size - shrinking back. Focus on important parts. Give people space to say what they wish for, and answer those queries
-
In the beginning of GSoC, do an ice-breaker event together. Playing a MUD with all students, mentors and admins surely is awesome fun -- and helps cooperation, community binding a lot!
-
give students responsibilities in the project. Account for this by reducing task size. You don't only want students to code but to be completely involved with your project!
- This can include participation in forums, wiki and the like as well as localization, PR, recruiting and so on. Be creative, retain fun!
