Feedforward
Things to bear in mind for next year
General
Sketch and disseminate a 'business process' style flow of information, so we are all clear on what documents go where, and who is responsible for each bit. For example, plan on letting speakers upload their own talks to the wiki, rather than emailing them to us.
Roles
Travel co-ordinator: This is basically just replying to email queries about travel arrangements and getting to the venue. There seem to have been a lot of last-minute questions about this by email. I guesstimate they are mostly from speakers rather than delegates. Much of this information was already available on the website. It might be worth appointing a volunteer to handle this relatively simple task, so that John and other overworked major contributors don't have to deal with it.
Submissions
The submissions form should label each input field with specific instructions about about what we need in it. Effort getting this right up front seems a good investment.
The form should have an unlimited length 'title' field, plus a short (35 char?) 'snappy title' field for use on the timetable. There is then no need for the 'description' field. (ie the description field is renamed the title field, the title becomes the 'snappy title')
The abstract contains all background and description of talk sections, timings, etc.
Have a tags field which can contain multiple tags. New tags should be easy to create. The submitters do not create tags, talk schedulers do. This is in addition to a category field, which I understand from Mr Pinner already has other uses. (for delegates to see what a talk is about?)
Make very clear to submitters what is required, especially we need to improve what we tell them about the picture we need:
- Head and shoulders, no trees growing out of heads
- Size 500px wide
- sensibly named, eg surname_forename.jpg
sensible content, eg no avatars or cornfields
We should ask submitters to mention if they intend to propose a sprint in the talk, so that we can tag such talks, and avoid scheduling them simultaneously.
I've (tartley) been maintaining a separate spreadsheet of talks, to keep track of the following boolean fields, which perhaps should be on the talks django database:
- speaker knows (the speaker definitely knows they are accepted, ie. they have replied)
- feedback sent (feedback about required fixes has been sent to speaker)
- is ready? (title, description, abstract are good to go to the printers)
- has photo? (speaker has an acceptable large enough photo)
'is ready' overlaps a little with the multi-value 'status' field that is already on talks, but maybe having it as separate boolean is more useful. 'has photo' should really be a field of the speaker, and perhaps is implied by the simple presence of a photo file.
Reviewing submissions
Guideline: Try to do everything in one pass. Even a minor subsequent change or check, when applied to every talk, can take ages.
Is it possible to allow submittors to see (and update) their own submissions, since passing them through us by email forms a bottleneck and generates work.
When reviewing each talk:
- edit the submission for grammar, capitalisation, spellings. Note that Django doesn't merge simultaneous edits - appoint one person to do this.
- If any significant edits are made, mention them prominently in the reviewer comments so that the champion can 'suggest' these changes to the speaker along with any other requested fixes.
- populate the tags field (subjects covered, eg 'frameworks', 'django', 'web', plus a 'sprints' tag for talks that introduce them.)
- If on IRC, paste the log wholesale into the reviewers comments field immediately at the end of each talk review, and maybe delete any swathes of irrelevance. It's just handy to refer back to.
Feedback to submitters
After accepting talks, send a very short email to let the submitter know, which only asks them to acknowledge receipt. That way a dialog is opened as quickly as possible, letting everyone know the most important info (ie. 'you have been accepted' and 'I confirm I saw that') as fast as possible. Then afterwards follow up on that to negotiate details.
Consider the idea of the follow-up negotiation being a series of small quick requests, rather than a single monolithic email, which people seem not to read, but simply to file for later.
Updates from speakers
When receiving updates from speakers:
- talk slides from speakers
- photos and bios from speakers, tutors, keynote speakers
tutorial handouts & tutorial prerequisites from tutors
Provide some way for them to update their own directly. Passing them via us (via email) makes us a bottleneck and wastes our time,
In particular, prerequisites from tutors should be (are!) already in the tutorial submission - these should be fed into the wiki or somesuch, so they can be used verbatim going forward.
Scheduling
Schedulers should plan a weekend to physically get together and create the schedule (unless someone creates a brilliant collaborative online scheduling app sometime between now and next year)
See wiki page http://wiki2010.europython.eu/TalkSchedulingConstraints for example things to consider.
Registration
Adding a "willing to share room" tickbox into the registration form, and auto-generate room-sharing wiki page. Put a link to room-sharing wiki page on the registration form, so people can check and arrange a room before they register.
Guidelines and Policies
The recent diversity initiatives have highlighted a few areas where policies and guidelines could be beneficial. We should make a few things explicit:
Photography: EuroPython has been quite liberal with regard to photography, and although there may not be any reason to change this, we should indicate that people are likely to be recording the event whilst advising photographers to exercise discretion - it's not the red carpet at Cannes/Vegas!
Presentations: although EuroPython regulars know the boundaries of good taste, we should remind presenters that we expect such boundaries to be observed.
