Talk:Czech Hackfest 2009
I'm really interested in the following item that's on the agenda: "Synchronising grades between Gradebook and modules like quiz that automatically compute a grade. What happens if the teacher edits in the gradebook so the grade becomes locked, then the student re-attempts the quiz and gets another grade?"
Will any transcripts or recordings of the discussions be made available to "non-attendees"?
- Luis, thanks for your interest. There'll hopefully be some meeting notes. --Helen Foster 09:18, 5 December 2009 (UTC)
Suggestions for things to discuss
- Synchronising grades between Gradebook and modules like quiz that automatically compute a grade. What happens if the teacher edits in the gradebook so the grade becomes locked, then the student re-attempts the quiz and gets another grade?
- Decide about the PARAM_XXX cleaners, where they can be used and other types of validation (just simple types, allow DB access too, only use them for param cleaning, PARAM_XXX as regexp constants, PARAM_XXX extensible via /local stuff). But in any case, must be decided and documented once and for all.
- Talk about adding class="moodletarget_xxxx" to links we were sending to new page via target="_xxxx" (non XHTML anymore) and post-process them with JS.
- Discuss about date/time/timezones/calendars in 2.0. One initial point of reference: MDL-18375
- planned changes in themes
- future of assignment module
- performance problems
- cron processing
- large scale moodle set-ups
- webservices and integrations with 3rd party systems, CLI tools
- Integrating paintweb?
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)
Probably more yacking than hacking....
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)