Czech Hackfest 2009
Work in progress here - do not rely on this yet.
- Saturday 5th December 2009
- Meet each others in Prague (some arrive, some may be there already)
- Settle down in a hotel - probably  or  (we are discussing with them to get some sale, do not book anything yet).
- Explore Prague (Castle etc)
- Social beer event
- Sunday 6th December 2009
- Leaving Prague together by a rented micro-bus (about 120 mins)
- Lunch at Jested, Liberec.
- Moving to the mountains (by bus or car or foot ;-), according to snow conditions)
- Accommodating at Jizerka
- Monday 7th December 2009
- Moodle 2.0 release planning
- Triage of remaining bugs (assign developers, priorities)
- Bug sprint
- Tuesday 8th December 2009
- Moodle 2.x planning
- Creating detailed roadmap for all modules based on tracker
- Wednesday 9th December 2009
- Moodle 3.0 brainstorming and planning
- Moodle 2.0 bugs
- Thursday 10th December 2009
- Moodle 2.0 bugs
- Friday 11th December 2009
- moving back to Prague on Friday
- more Prague sightseeing
- Settle down in a hotel - probably again  or  (we are discussing with them to get some sale, do not book anything yet).
- official end of hackfest
Attendees and arrivals
Maximum of 16 places, so far we have (in chaotic order):
- Martin Dougiamas
- Eloy Lafuente
- Petr Skoda
- Tim Hunt
- Helen Foster
- Penny Leach
- Dan Poltawski
- David Mudrak
- Shane Elliott
- Chris Roy
- Brian King
- Daniele Cordella
- Mike Churchward (TBC)
- Hubert Chathi or Justin Filip (TBC)
- Iñaki Arenaza (TBC)
- Matt Oquist (TBC)
I wanted to add some ideas of things we could talk about, and for some reason I did not want to use the talk page so I am adding them here. These are just ideas. Take them or leave them.
What is the balance between Yack and Hack?
That is, how much time will we be talking, and how much time writing code on our laptops?--Tim Hunt 09:41, 8 August 2009 (UTC)
Planning specific bits of the post 2.0-roadmap
The main thing is that we keep talking about how recent released, especially 2.0, have had a lot of under the hood changes and that we really need to do some work on the actual activities themselves. I was wonder if if we should have a section of time allocated to what we consider the most important modules (or other things like the gradebook/filepicker/backup).
In order to have meaningful discussion, I suggest that in advanced of the hackfest, each participant is assigned (or volunteers for) one of those bit. They are then expected to read every open bug and feature request for that component, and spend some time following the associated forum, and come up with a summary of what the most pressing issues there seem to be. Then at the hackfest they would lead that discussion section, kicking off by explaining to the rest of us what they learned during their research.
Naturally, if we do this, I volunteer for the quiz and question bank. Of course, I already have a pretty good idea what is going on there. I guess this would probably be more work if people had to look at an area they had not thought about before, so that is not fair.--Tim Hunt ~10:00, 6 August 2009 (UTC)
- +1. Naturally, I volunteer for Workshop, given that the Tim's last sentence applies for my case, too. --David Mudrak 10:51, 7 August 2009 (UTC)
How about a work-on-2.0 day
The aim would be that by the end of the day, we have fixed as many of the Fix-for 2.0 bugs as possible, and also have reviewed all the ones that we cannot fix immediately, so we end up with a really good, triaged bug-list of what is left to be done. By the end of the day, all the bugs should be assigned to someone who feels confident they will be able to fix it.--Tim Hunt 09:41, 8 August 2009 (UTC) and Dan Poltawski. We discussed this at the GBBF last night.
'Prepared' Bug Squashing
Basically the same as the above suggestion, but I want to emphasise some preperation beforehand so that we can get to the real unsolved issues which would benefit with us all being in the same room and discussing solutions.
With each bug we triage before the hackfest, we should try to:
- a) Link or close issues which have been fixed, or will be fixed by 2.0 (etc)
- b) Document unsolved issues which we need discussion or a plan to be fixed (this is most important for the hackfest itself)
- c) Document bugs which could be fixed with a little time (at the hackfest or later)
- d) Document bugs to pester someone else about ;-)
Depending on how much time you can devote, I suggest trying these triaging views in order:
- 1) Reviewing all open bugs reported by yourself, starting oldest first.
- 2) Reviewing your assigned issues, starting with oldest first
- 3) Reviewing 'nobody' or 'imported' bugs starting with the oldest first.
There is a lot of old cruft in the tracker. Many of the issues have or will be fixed soon, so we could do a lot by just looking at our own issues and setting the status/links appropiately. For all the others, some are just without a decided solution - these would be great ones to at least think about discussing. --Dan Poltawski 17:28, 15 August 2009 (UTC)