[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Debconf-team] Accommodation numbers/upgrades/communal accommodation



Hi Gaudenz,

On Mon, May 20, 2013 at 10:29:52PM +0200, Gaudenz Steinlin wrote:
> > [Ganneff: Could you please add a munin graph with the answers to the com_accom
> > question or provide the numbers by email, Thanks]

> > Moray Allan <moray@sermisy.org> writes:

> >> We are now (by tomorrow) at the end of the period for applying for 
> >> sponsorship, so the next set of decisions about room utilisation etc. 
> >> should be made soon.

> >> How many people have registered for what room categories currently, and 
> >> how does that compare to the available rooms?  How many sponsored people 
> >> said they would/wouldn't take "communal" accommodation?

> > The room categories are visible in this munin graph [1]. Additional data
> > about the "Debian role" is available in the admin interface. 

> > Current status:
> >                                 All / accompany / interested / None / not selected
> > Own accomodation:               26 / 0 / 10 / 3 / 0
> > Sponsored accomodation:        121 / 0 /  5 / 0 / 0
> > self-paid communal:             16 / 0 /  3 / 1 / 1
> > self-paid camping:              13 / 1 /  0 / 0 / 0
> >                                (+ 20 requesting sponsored accomodation and prefering camping)
> > self-paid 8 bed:                27 / 1 /  3 / 1 / 0
> > self-paid 2 bed:                27 / 0 /  2 / 0 / 1

> > Not taking into account any additional requirements this means we have
> > enough rooms for all these requests.

> >> We should clarify soon for people already registered what kind of room 
> >> they can expect to receive, and, e.g. give them the chance to pay for a 
> >> better room if they aren't happy with that one.

> > I think we should as soon as possible confirm the rooms for those that
> > choose a self-paid room. For the upgrades we have first to find a more
> > or less consensual way of doing this. As a discussion basis for this we
> > need to know the answers for the survey questions. AFAICS these are
> > currently not accessible in a munin graph or in the admin interface. As
> > it looks now, we still have beds available in each category.

> I just got read access to the penta DB and tried to retrive the data
> about the communal accomodation survey [1]:

> 95 would accept communal accomodation
> 17 would *not* accept

Thanks for running this query.  It seems that the models advanced for
sponsored attendees by the local team are reasonably accurate, then, and
there is no need for major adjustments to the undersubscription of the
rooms.

Just a couple of things:

 - The early query showed a total of 121 people requesting sponsored
   accomodation, and your query only includes 95+17=112 of these people.  We
   should understand where the other 9 people are.  Have they requested
   sponsored accomodation, but failed to mark "I want to attend this
   conference"? Or are they missing for another reason?  If people failed to
   mark "I want to attend", we should probably consider that a schema bug
   and include such people in the count of possible attendees.

 - I'm very confused by what I find at
   <https://wiki.debconf.org/wiki/DebConf13/Pricing>.  I understood that
   there was very strong opposition to filling the largest rooms to their
   nominal capacity; but this chart shows all rooms with 8 or more beds
   being filled to capacity.  And looking at
   <https://wiki.debconf.org/wiki/DebConf13/Pricing/Compromise>, I see it
   redirects back to <https://wiki.debconf.org/wiki/DebConf13/Pricing>...
   and that the last version of /Compromise matches.  So I'm concerned that
   this page doesn't actually represent a shared understanding of how the
   rooms will be allocated.  Could someone please either confirm that we
   *are* planning to fill these large rooms, or else fix /Pricing to reflect
   the actual plan?

FWIW, assuming the "worst case" scenario - that the missing 9 people between
the two queries do plan to attend, are granted sponsorship, and will not
accept communal accomodation - that gives us 26 sponsored attendees with a
"non-communal" requirement, and 138 attendees registered *so far* who want
communal accomodation (both sponsored and non-sponsored)[1].  And there are
a maximum of 207 beds available across this accomodation class, meaning
there are still 69 spaces potentially available for non-sponsored attendees
who register between now and the start of the conference.  Obviously
self-paid attendees don't have the same deadline for registration so we will
see some number of these registrations come in later, but that's 160% of the
self-paid attendees in these classes so far.  So I am *guessing* that we're
in good shape for accomodating everyone's needs, and will have a bit of
extra capacity left over that we can use to give folks in the larger rooms
more space.

Furthermore, there are 63 beds in the <= 4 rooms reserved for sponsored
attendees, and at most 26 sponsored attendees who have expressed a hard
requirement for them (without regard to whether they're willing to pay a
supplement to get them).  Given these numbers, I think the right thing to do
is to fill these reserved rooms with sponsored attendees at no extra charge
(giving precedence to those who have a hard requirement), reducing the
overall occupancy of the larger sleeping bag rooms while at the same time
increasing the number of communal spaces available for self-payers.

That looks like:

 - 164 attendees (sponsored+non-sponsored) in rooms >=3 people
 - 63 sponsored attendees in the reserved <= 4-person rooms
 - 27 self-paid attendees in the 8-person rooms, only filled to 6
 - 9 sponsored attendees in the 8-person rooms, only filled to 6
 - 16 self-paid attendees in the medium/large sleeping bag rooms
 - 49 sponsored attendees in the medium/large sleeping bag rooms

With the current numbers, given that there are 9 communal rooms, that
actually comes out to a maximum of 8 people in *any* room.  But of course,
it's the communal rooms that would have more people added to them as more
self-paid registrations come in.

> >> (That doesn't necessarily mean cheaper "upgrades" beyond the current 
> >> pricing, as some team members suggested, but we should start to clarify 
> >> things beyond the very vague options most people selected so far.)

FWIW, if the numbers were different and showed there was more demand than
availability for the small capacity rooms, I would support allowing
sponsored attendees to pay a supplement for an upgrade.  But unless the
numbers change a lot more than I would expect over the next couple of
months, I think the only fair way to do this is:

 1) allocate self-payers to the class of room they've paid for
 2) allocate the "non-communal" sponsored attendees to the small rooms
 3) distribute the rest of the sponsored attendees evenly between all the
 rooms

In particular, I think it is *not* reasonable to leave small rooms empty
while sponsored attendees are crammed into the sleeping bag rooms simply
because the budget calls for bringing more income from sponsored attendees.

The only other option I see here would be to open up a second call for
sponsored attendees (with no travel sponsorship - we can't afford to delay
the herb team's work on travel sponsorship approval).  Then maybe you get
enough sponsored attendees to justify treating accomodation upgrades as a
paid premium.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[1] I think someone moved the line for "communal" vs.  "non-communal" after
the earlier discussions, I consider 8 people in a room "communal" and am
considering it such for this analysis.  I'm pretty sure the distinction is
purely semantic for purposes of this analysis; but if someone wants to
re-run these numbers with "8 people per room" excluded, feel free.

Attachment: signature.asc
Description: Digital signature


Reply to: