FrequentProblems

Frequent problems

Volunteer neglect

Problem: On the mailing lists, at face-to-face local team meetings, and during DebConf, many people volunteer to help with DebConf work. Many more are willing to help with tasks if asked. Debian people normally have the attitude that the right way to join a team is to just start working, but this can mean that volunteers feel unneeded or simply don't know where to start.

Solution: Welcome new volunteers (even if this seems unnecessary noise on IRC or on a mailing list). Listen to their interests and skills, then suggest something appropriate to them where they can help. Make sure that someone more experienced works with them initially, and make sure to ask them how they're getting on and to help them if they get stuck. It's common that on the first piece of work, the experienced person will take longer helping than if they had done it directly themselves, but the time will be recouped in subsequent work.

Video setup

Problem: Often we need last-minute negotiations to get access to the talk rooms for video equipment setup. Bookings may mistakenly only be made for the days when talks will actually happen, but the video team want access to the rooms for as long before as possible.

Solution: Make sure that talk room bookings start several days before the room will first be used for talks (speak to the video team to check how many days are needed). We have previously coped while there were occasional non-DebConf events in the talk room during the setup period (speak to the video team in advance if you think this might happen!).

Scheduling

Problem: The video team already work very hard, and event schedulers can make their work much more difficult by certain choices.

Solution: Talk to the video team before finalising any timetable for talks, making sure to agree how many rooms can be covered, for how many hours, and the earliest sensible start time and latest sensible finish time. Also agree on how long a gap will be left between talks -- even if the rooms are close together, the video team will probably want 15 minutes' break left between events. Allowance for speaker overrun and question periods must be included in the event timings, not taken out of the breaks.

Debian Day

Problem: Despite good intentions, this often ends up neglected around the DebConf period. For example, it is usually not advertised enough, since the people who would do that are busy on more pressing DebConf tasks.

Solution: Make sure at least one or two people work on Debian Day who do not have any other DebConf work from several weeks before Debian Day until after Debian Day is finished.

Communication between global and local teams

NOTE: this is all in flux, as the DebconfOrganizationWorkingGroup aims to create a new organisational structure and hopefully gets rid of the "geopgraphical" distinction between local/global teams. Madduck (talk) 05:32, 12 September 2014 (UTC)

Problem: Sometimes the local team forgets to communicate with the rest of the global DebConf organisation team, or feels that the global team is being too conservative, not listening to its new ideas.

Solution: The global team should remember that the local team are the ones physically present (as well as being the ones doing much of the work), and remember that some decisions are made more easily by those who are on the scene. At the same time, the local team should remember that the global team may have seen the new idea tried before and failing, even if they don't explain that clearly. Everyone should remember that DebConf isn't for the benefit of the global or the local team, but for Debian. Typically it's good to have formal IRC meetings with the whole global team once a month for the first part of the DebConf cycle, increasing to fortnightly then weekly as DebConf gets closer. Major decisions should be discussed on the -team mailing list, then formally progressed during a meeting. Even if there only seems to be one realistic option for an element of local organisation, it's better to discuss that, and the reasons why, rather than surprise other team members later on.