TravelSponsorship

This page is designed to organize our thoughts on DebConf travel sponsorship.

The current system (DC13-DC14)

• Conference registration is opened at least 4 months before the start of the conference, and ideally 5 months.
• A deadline is given for sponsorship applications - ideally, 3.5 months before the start of the conference.
• Everyone requesting sponsorship fills out the related fields in the registration system: how much their travel expenses are, how much help they need, and enough information to tell the team why they should be sponsored.
  • question: should information be required about where they're traveling from, to sanity-check amounts?
• About 4 months before the start of the conference, a bursaries team is assembled to rank, and approve/deny, sponsorship requests.
  • This team aims for diversity of viewpoints: long-time DDs, local DebConf team members, DebConf attendees
  • The team agrees on a procedure for ranking travel sponsorship requests.
    • [Summit]
  • Team members can use the bursaries@debconf.org alias as private mailing list.
• The team ranks all of the sponsorship applications, emailing requestors as necessary to get clarifications. Rankings should ideally be done by 3 months + 1 week before the conference.
• People are notified by 3 months before the conference if their sponsorship is definitely approved or definitely rejected.
  • There may be some cases in the middle which can only be approved if the money becomes available (e.g., if someone higher in the list decides they don't need sponsorship, freeing up travel money; or if someone who was rejected for travel sponsorship decides not to come, freeing up food/accommodation money to be used for travel sponsorship instead). These people may be told that there is not money available "at this time" to provide them with travel sponsorship. If there is a further round of travel sponsorship because more money becomes available, this should happen quickly, because people's plans and ticket prices will change.
• People submit forms after the conference, [e]mailed to SPI or FFIS, and after some months, they'll get money back.
  • This is an area for improvement; we don't want people to wait months for their money. How can we improve this?

How it worked, DC?? to DC11

• Everyone fills out the travel sponsorship related fields in penta. Deadline is the same as registration deadline.
• Early, a team is formed to do rankings of people.
• The team goes through and uses a penta system to rank everyone who has applied for travel sponsorship in terms of "contributor level" (how much they deserve sponsorship) and "requested amount" (how much they are requesting, relative to how much it should cost from where they live). There is a total score which is a (possibly weighted) average of these ratings.
• The team doesn't start ranking until after the registration deadline, usually some weeks after.
• People are sorted via their scores, and there is a list of cumulative costs so that you can say "first 10 people cost AAAA€, first 20 people cost BBBBB€".
• There is a meeting where the team decides who gets what. This could be by picking the top N people, saying they get money, the bottom M, saying they don't get any money. They discuss the people in the middle, making adjustments to amount received if necessary, and then look at any other exceptions to the three categories.
• People are notified of their allocations some weeks/months before DebConf.
• If more money becomes available, another round of allocations might happen.
• People submit forms after the conference, [e]mailed to SPI or FFIS, and after some months, they'll get money back.

Administrative work

A member of the bursaries team has to do the administrative work of collecting all the documents needed from sponsored attendees:

• Check with the different involved organisations doing the payments about their requirements regarding documents (paper or electronic) and the most current version of any forms that should be filled.
• Contact all the sponsored attendees during DebConf and tell them how you want to do the administratie work.
• Collect travel documents and copy them as a proof of payment.
• Make them fill out the right form with all the information where to send the payment. The process is slightly different depending on where the money comes from (SPI, FFIS, debconf13.ch, cash, ...)
• Send everything (signed) to the organisations actually doing the payments. CCing the debconf chairs so that they can approve the payment.

Budgeting considerations

• Amount we have to work with isn't known until close to the conference.
  • At DC11, most sponsors were not pledged until two months before the conference, so the budget is very uncertain even
• Most money does not arrive until a little bit before, or even after the conference.
  • For example, for DC11, two months before the conference we had less than 10k € received in bank accounts.
  • Most people have been paid back months after the conference, so cash flow for reimbursement has not been a problem recently: but we should be aiming to pay people back immediately when they purchase tickets
• There is a 10-20k € surplus carried over from year to year, typically.
• Historically, Debian has provided "insurance" or support for travel sponsorship. For example, at DC10 Debian offered to contribute 10-20k USD as a backup to DebConf if it helped to get travel sponsorship out early. It turns out that this was not needed and not claimed.
• It is darst's impression that Debian would be happy to contribute insurance money early to use to underwrite travel sponsorship allocations before sponsors' pledges began coming in. This money would almost never have to be actually claimed.

Ideas

• Have a BOF at dc11 to discuss how to do things.
• Use the DCN's rankings/allocations to guide an early round of funding for DCN+1.
• Have people submit the forms _at_ debconf, not mailed in afterwards. And have a firm deadline of "Last day of DebConf" to get papers turned in. That will help reduce the wait time for reimbursement.
• Ideally that "last day of DebConf" should be a final deadline, but as many people as possible should already be reimbursed (long) before DebConf.
• Streamline the form process: sometimes it has taken several different rounds of sending forms in.
• Turn the DebConf team into a Debian travel sponsorship team, that is used for other things like the sprints.
• Have more than one round of travel reimbursement
  • DC10 had two rounds, but it was "late" and "later", not "early" and "normal". The reason for two rounds here was making sure we had enough money.
  • People have intended to do this idea before, and the main reason it hasn't happened is that herding the cats to do the ratings and get something out is _hard work_. There would be little objection to getting ratings done earlier, and then people _would_ see to it we'd have money to allocate early.
• How do people decide what amounts to request?
  • Guessing actual flight costs is hard -
  • Some people put in a low estimate their flight costs, figuring that it makes it more likely they'll get sponsored.
  • Some people put in a high estimate, figuring it it better to be safe than have to pay some themselves, OR that they might get funded at only a fraction so why not overestimate?
  • Even if you over-request sponsorship, you only get reimbursed for the actual costs, so there's not an incentive to guess accurately to save DebConf money. (but you _will_ allow more people to be reimbursed)
  • How could we make it so that entering the most accurate total flight costs, and the amount they would actually like to be reimbursed, is the best option for attendees? How can we minimize the need to game the system?
  • Could there be some way to enter the amount they have purchased tickets for as soon as they book a flight, so that can be taken into account when making future decisions? ("Costed less? Good, now we have more money." Right now we can't make use of that.)
  • Also, right now people can't adjust their amount requested based on changing flight costs. Allow that somehow? Allow people to lower sponsorship?
• Have the team consist of people from each continent, and each area of a continent if it is big. That way, hopefully someone on the team will be aware of general costs to from each region without each member having to search travel costs for each applicant's home.
• Communicate. Send mails liberally, even if it is just "not yet". Same goes for updates to the team (this should be obvious, but is worth stating again).
• How much is it a job of the team to help applicants? For example, if you notice that someone has a flight cost you know is too much, do you ask them to lower it? Do you ask someone to enter in a better reason if that is what they need? (see below)
• Which is more important for getting sponsorship: being active in debian (search of *.debian.org), or putting in a reason to need sponsorship?

Rolling vote

I (fil) was considering that it might be possible to make the process more continuous, but this would need to be informed by things like what normal rates of incoming applications are, and normal rates of incoming sponsorship, but here's the kernel of the idea:

• establish a fighting fund (at least on paper) by getting agreement from Debian well in advance that they'll cover 10k (or 20k?) even if DebConf gets no sponsors at all, and the whole thing is canceled.
• as applications come in, team members are expected to put the applications into an order relative to the other applications already in the system, such that we can then use Condorcet to get an overall ordering.
• whenever there are sufficient applications to make the vote interesting, and there is a run-away winner (or cluster of winners) we compare what we have unallocated in the fighting fund (on paper, we don't worry about whether it is in the bank) and apply that to some or all of the winner(s) expenses.
• whenever there's a runaway loser (or cluster), we send them a "We're sorry, but unless funds are more than expected, we don't think we will be able to sponsor you this year" email.
• Perhaps we then eliminate them from future rankings at this point, although I think it would be best to keep them in, but run subsequent rounds of Condorcet twice, once with everyone in, and once with all the previous winners/losers removed.
• at regular intervals, we'd need to have a meeting to check if this process is really working, or if we've just decided to fund people that would have been rejected in previous years, say -- in which case we can always fall back to the old system
• as believable offers of sponsorship come in, we add them (or perhaps a proportion of them until we have the money) to the fighting fund to enable
• we make sure that everyone knows this is how things are going to work, and that it favours early applicants unfairly, which should get people to apply early (this obviously requires that we have firm dates for Debconf early)
• we could probably start this as soon as we have firm dates
• we can test the prototype of this process on sprints through the year (although I'd imagine that we fund a much higher percentage of the Sprint applicants, so it might not be a brilliant test)
• Miscellaneous thoughts
  • I'll need to check, but I have a feeling that we can simply ignore voters ranking for themselves in Condorcet, and it will come out fair, so that could be how we deal with the conflict of interest.
  • I worry slightly that any system that we have will disproportionately favour friends of the team, but on the other hand their is inevitably going to be a high correlation between those and the people we really want to fund
  • it might be good to try and draw new team members from under represented subprojects since they might have useful opinions about people that others don't know at all -- the voting thing at least should scale, so perhaps we could have a wider poll of voters, with a core team for using those votes to inform the funding decisions (I don't want to chair a meeting of fifty people, especially when money is being discussed, thanks)
  • the voting thing should decouple people's deliberations from the funding decision
  • we don't necessarily need to wait for the last vote to be in to make another batch of decisions
  • when we get to the end of the precess, and need to have a meeting about the last lot, we'll have an ordered list already, which should be helpful
  • the voters should know the funding situation day to day, and do their ordering based both on the merits of the candidate, and the amount being asked for, as though they were making the decision on their own
  • if the funding situation changes radically from expectations, perhaps we should allow voters to reorder some or all of their votes (I'm not sure what would happen if a block suddenly decided to down-vote someone we've already given money to, but I suppose we should worry about that when it happens).
  • actually, voters should always be allowed to reorder votes, since these are the rankings we'll be using at the end (if people start gaming the system we'll kick them out of the team)

darst plan

• Select team randomly based on DCM (debian community members) participanting in DCN-1. Say this is a duty of yours, if you have even accommodation sponsorship (now or sometime in the past).
• Rate "need" based on how they describe it:
  • I need travel sponsorship, as incomes in my country are too low to afford this.
  • I need travel sponsorship, otherwise I would have to give up things necessary for my life such as food or transportation.
  • I need travel sponsorship, or else I would have to give up my personal travel.
  • I need travel sponsorship, or else I will have less personal savings.
• Try to diversify who gets funding, based on these categories:
  • Financial need
  • Active Debian technical work (number of packages/infrastructure maintenance)
  • Active Debian team leadership and visibility
  • Desire to bring in new members of the Debian community, people whom are not yet active.
• Select people every two weeks. This means that if you apply late.
• Judge people based on web_search("$their_name site:debian.org")
• Judge total cost based on travel search engine and compariason for others from a similar area.

References

• Big thread from DC10 BOF, including notes.
• Threads from DC11: main one fragment