On Thu, 3 Jun 2010 15:14:41 +0200, Ana Guerrero <a...@debian.org> wrote:
> > What we did
> > -----------
> > We tried to decide which talks would be scheduled for the two main rooms
> > ("interschool" and "davis") during daytime hours, addressing it as a
> > challenge to "cut" proposals based on (a) the ratings in pentabarf, and
> > (b) the number of time slots we expect to be available for those rooms.
> >
> > We set aside those proposals which did not belong during daytime hours,
> > and we divided the remaining proposals into "accepted for scheduling in
> > the two main rooms" and "not accepted for scheduling". We started by
> > accepting the highest 50 of the ranked proposals, turning down the
> > lowest 20, and then went into a deliberative process over the remaining
> > middle as to whether they should be accepted or not.
> >
> > We then worked on wording for mail that would be sent to the authors of
> > the two categories of proposal. [1]
> >
>
> All fine here.
The problem here is that we turned down the lowest 20 for one reason
(relative ranking in penta), and then turned down a select group of
other talks in the middle for other reasons (we have a limited set of
slots for the two main rooms, we want to see the talk happen, but it
makes more sense to have in Schipiro).
When we went through the deliberative process over the remaining middle
to decide if they should be accepted or not, we were making decisions
that were based on fundamentally different understandings in some cases
than others. In the end we have a set of talks that are in state
'rejected' that we don't want to actually send a rejection notice,
because we want to see them happen in Schipiro.
> > What we missed
> > --------------
> > In writing up the mail for the "not accepted for scheduling" proposals,
> > it became apparent that we would encourage the authors of those
> > proposals to schedule their proposal in some other room -- it became
> > apparent that 414 Schapiro seems a likely candidate, and we might even
> > be able to get other classrooms.
>
> Here is the problem we hit on previous years and lead in the creation
> of the infamous "unofficial" track:
> we reject your talk but you can do it "unofficially". There is not
> difference with the "official" talks. At least not with the ones
> schedules from the beginning (difference here: video recording)
since we are avoiding the 'unofficial track' this year, because of the
problems it causes, we are effectively left with a confused state of
affairs. there are a set of talks that are in state 'reject', but we
don't actually want to reject, we don't want to tell those people that
they are unofficial, but sending them an email that says your talk isn't
going in two rooms, but there is a third room that you can figure out
for yourself, is basically saying rejected or even 'unofficial', when
those talks we didn't actually pick on the grounds that they should be
rejected, just that they didn't fit in those two rooms.
> What I understand here: you were worrying about scheduling again instead of
> looking what talks should be accepted and what talks should not be.
Its not actually scheduling, its talk selection based on available rooms
and available time slots. Ana, you came up with a calculation for how
many talks should be accepted which was based on two rooms being
available. When we realized there was a third room available, we made
various rejections based on the idea that we want to see those be put in
that room, not actually to reject them.
> > These allocations wouldn't be perfect or fixed in stone, but would help
> > whoever does scheduling to see where they might fit best.
>
> As mentioned, we should not do talk selection and scheduling (room talk
> allocation) at the same time. Firstly, we just should select the talks we
> see fit and seem good for Debian and reject all that does not fall in this
> category. Then we worry at how use the resources we have.
I dont think it is so easy to separate those two things. For one, if we
were to select all the talks that we feel are fit and good for Debian,
we would have too many talks for the two rooms. The categories of what
talks fit and what talks do not fit are connected to the number of slots
and rooms that we have. This is why this calculation was made.
We either needed to use one criteria or the other, not both. If we used
the criteria that a talk was good enough for debian, then we would not
have rejected some of the talks that we did because we rejected them
based on the 'number of slots we have available for two main rooms
criteria' and that there was a room that they would go into.
> Also, we have plenty of last time stuff from ideas people come up during
> the weeks previous to DebConf (sometimes even during DebCamp and DebConf),
> and most of the time this last minute bofs/talks are very *good*. I think
> this side of unconference of DebConf is very productive for atteendess.
> So if we end accepting only 70 talks, do not worry, we won't have "empty"
> places in the schedule, some proposals that will come last minute can go
> there. We should reserve some space for this last minute/weeks talks.
We definitely need to reserve space for last-minute things, however even
if we go ahead and accept the 26 remaining talks that are in this weird
state, we still have over 10 slots left over that are not allocated, do
we need to allocate more than 10 slots for last minute things? That
seems like a good number to me, but I'd also be open to leaving more, I
just don't think that we need 36 open slots!
> Answering to "What should we do?" my suggestion:
> - Accept 65-72 talks we believe are good for debconf. Send accept/reject
> email. Publish list of accepted talks without scheduling. To rejected
> talks add we are studying the possibility of a extra unconference talk that
> does not need to be necessarily recorded and still to be decided.
I agree that we should send the acceptance email. The problem is sending
the reject email. We don't want to send a rejection to the evening
events, we dont want to send a rejection to things that we want to see
happen in Schipiro. We dont want to send things to people who submitted
a talk that we actually liked and we wanted to happen, but we thought
should happen in Schipiro an email saying "sorry!" when we actually want
to tell them that their talk is accepted.
> - Keep allowing late submissions in penta.
> - Gather talks requirement and schedule the accepted talks in the 2
> main rooms.
I would propose that the best way forward, at this point, taking into
considerations all the discussions here and on IRC would be this:
1. send an acceptance to all the currently 'accepted' talks in penta, we
don't bother including the 'two main rooms' details. it was accepted,
implementation details come later
2. send a reject notice to the bottom 20 that did not make the cut due
to the ratings
3. accept in penta and send an acceptance email to the middle third that
we had such a hard time deciding on last night, this email would be no
different than #1
4. we schedule Schipiro (414) along with the two main rooms
Doing this will result in plenty of room for last-minute space for
talks. Determining what to do with talks that were actually rejected
that are later re-submitted as last-minute would be up to the on the
ground schedulers.
Schedulers will have two unknown variables: if a talk wants V-T
coverage, and how many people might want to attend any particular
talk. These are the things that will make scheduling difficult, if we
don't know them in advance. If its at all possible to add something to
penta and request that accepted talks indicate, then we should to help
the scheduling.
micah
pgp1wSV751wMz.pgp
Description: PGP signature
_______________________________________________ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
