Last year we organized activities in three areas: Hacking, Training, Meeting. I think we should keep these three containers.

Do we have main themes for Lyon, as we had in San Francisco last week?

Hacking

• Bug Solved
• Lines of Code written
• Tool Labs accounts created

Training

• Workshop for beginners
• Survey to evaluate abilities improvements for coders

Meeting

• We'd like to have a moment to gather people interested in Wikidata and DBpedia for them to share their experiences.
• 3 talks, 1 per day, to still have time to code

Ideas:

• Wikidata ( @Lydia_Pintscher would you be interested?)
• Open Street Map ?
• Vagrant ?

Regarding main themes, we were considering Wikidata and maps, in order to continue what has been started last year.

We asked Lila, and she is proposing a radical change, actually more in the pure spirit of hackathons:

I think the more important part is not the structure but the process and outcomes. I want us to re-imagine what we want these events to be. I'd like to see them being "accelerators" of labs and productized products as well as a way to identify community people who might be capable of leading independent feature development.

With that goal in mind -- we want to focus on teaming, prototyping and demonstration -- i.e. building out a way to demo the feature prototype by the end of the event with maybe fun prizes or even a "fellowship" for the team to flesh out the concept. I don't think we should restrict the areas of innovation at all as long as the hacking is demo-able.

I must say I really like this.

Thus, what Lila is suggesting is that we stop middle-term projects which are developed one Hackathon at the time (such as Maps or Flow for instance) but focus instead on projects that can be finished in 3 days?

I really like the new perspective but I wonder if we won't lose the community spirit of the event? Prizes imply competition.

For us in France, it doesn't change that much the process of planning, I'll submit this idea to our hackathon community and I'll get back to you for a feedback. :)

Hi, I'm not sure how to understand Lila's message : if the goal is to encourage participation through a bit of gamification (set short terms goals that can be accomplished in a week-end through a demo/prototype), I'm all for it.

If the goal is to get completely rid of the work on long-term projects that is done during the time of the Hackathon, then I don't like the idea. I think we need both - and need to encourage both ways of action. On think to keep in mind is that people working on long-term projects generally are experienced users and open to take some minutes to answer specific questions (about how to do something with the API for example), which could be a great help for people working on the short-term demoable projects Lila describes.

"Demo-able" is the goal, the catalizator. Whatever you do, get organized with others so you have something to show at the end of the hackathon. The primary use case Lila has in mind are prototypes of new features, but the demo-able principle should be applicable to basically all areas: a collaborative effort on performance results in demonstrable faster uploads, an old nasty bug is now fixed, a missing document is now published, 20 absolute beginners uploaded their first patch to Gerrit...

To put a real example, I have started to discuss the possibility of going for T560: Proof of concept of code review in Phabricator to some people interested in this idea.

OK, it seems great. What would be the prizes? Barnstars or things with real monetary value? Who will decide who receives these prizes?

No idea about prizes yet. They should not be the main motivation in any case. Meanwhile: https://www.mediawiki.org/wiki/Hackathons#Demo-able_projects

Please check the measures of success proposed in the task description.