On Tue, Jun 25, 2013 at 3:00 PM, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
On Tue, Jun 25, 2013 at 01:31:28PM -0400, Josh Boyer wrote:
> On Tue, Jun 25, 2013 at 12:37 PM, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
> > = Overview
> >
> > In one of Robyn's early messages envisioning flock, she used the term
Do-Con
> > to embody what she was hoping could be achieved. The idea being that FUDCon
> > often ended up with less being accomplished than the participants hoped for.
> > A larger, more inclusive Do-Con would have a greater focus on having
> > participants accomplish tangible goals than the current FUDCon.
> >
> > If this is something we'd like towards for future flocks, I think we might
> > be able to help achieve that by changing the schedule process. In looking
> > at the schedule, I realized that I'm involved with a lot of different
> > portions of Fedora. As such, I'm a needed participant in many diverse
> > topics. I have the feeling that this affects many other people as well.
> > The core people that have time to spend on Fedora naturally acquire roles
> > in multiple parts of the organization because they have the time to jump in
> > and do work that is required. That works out well in the day-to-day work of
> > Fedora but when it comes to scheduling a conference, it means that they're
> > often involved in the topics that are taking place in two places at the same
> > time.
>
> Having read your proposal 3 times now, I'm not immediately seeing why
> the current flock schedule doesn't already accommodate your ideas.
>
> We have hackfests scheduled, but we also have an entire timeslot open
> for hackfests/talks/whatever Sunday evening, and then all day Monday
> is open as well. That allows for the scheduled talks and workshops to
> proceed, and then follow-on FAD type activities later. Also, there is
> at least one room (not counting the quiet room) that is entirely
> unscheduled from the later 1/2 of the second day onwards that can be
> used for whatever.
>
The problem is scheduling conflicts. For instance, I'm going to miss most
of the Future of Fedora track because I must be present in sessions that I'm
giving and in sessions where the discussion is even more central to my work.
Then it's clearly more important
The question is whether there's any way for me to attend all the
sessions in
three categories:
* The session I must attend
* The sessions I should attend
* The sessions I want to attend
While also allowing everyone else to attend the sessions that fall into
their three categories.
The last section suffers. I'd like to attend quite a few talks I
won't be able to, but that is a product of having good talks and not
being able to tailor schedules to individual needs. Having group
information might help, but won't magically make the problem go away.
At the moment, the only information that any one person has about
that is
their own personal fit into those three categories. Adding essential group
information into the workshop/discussion/hackfest proposals would let the
people planning the schedule determine more about the must attend category.
Then do that. Email the committee with that information now.
I'm frustrated that you've essentially written off flock as making
this "not possible" a month and a half before the conference even
happens.
> > * Workshop on porting Fedora to python3: (half day session)
Need at least
> > one person who has had success porting to python3 to impart knowledge.
> > Need someone from the packaging tools team, someone from anaconda team,
> > and a few people from the python SIG who are active on IRC or the mailing
> > list or as packagers. The goals are
> > (1) A plan for how Fedora is going to be porting to python3. (All at once
> > or piece at a tinme? Code that works in both python2 and python3 or
> > two trees of code? Minimum python2 and 3 version to target? Third
> > party libraries that help port?)
> > (2) A timeline to shoot for making python2 legacy (identify checkpoints
> > like, When will all of our essential packaging tools use python3?
> > When will anaconda use python3? When will we have only python3 on the
> > LiveCD? When will we only have python3 on the Installation media?
> > When can we tell people that code we write is no longer allowed to be
> > python2? When can we tell people that to be on the install media, you
> > need to target python3?)
> > (3) The people from the SIGs and teams to understand a little more about
> > the mechanics of porting code to python3 so that they can share
> > strategies with others and help port important packages.
>
> All of those people will be there. What is preventing this from
> happening with the current flock schedule?
>
Remembering that this is an example only, scheduling conflicts can prevent
people from attending. A real case would be that as a FESCo member,
I should be attending all of the sessions that deal with proposals to change
the Fedora release process. However, I'm going to be giving talks and also
must be involved in some of the infrastructure talks so I can't.
The question is, can I make due with only going to a subset of the talks?
Can you? Probably. Can the conference make due without you being
everywhere? Yes.
That's quite possible. For instance, a different set of FESCo
members might
go to the sessions for the proposals that I miss and then they can speak
with some knowledge about how that proposal would interact with the
proposals that I participated in and can speak for.
Right. Things that are by nature driven by committees are going to
require recaps and further discussion regardless.
But with the current information that includes only the speaker, not
the
group necessary to effect action, there's no way to know this.
See above about emailing.
To me the problem is: We can be pretty sure that a representative
selection
of people will be present at flock but we don't know that a representative
selection of people will be present for each session where they're needed.
I don't think that is a problem that is insurmountable. I also don't
think it's a problem that some people have conflicts because they're
involved in a huge number of activities or committees. Those
conflicts can be handled by other members with recaps, or *gasp* by
new people volunteering or being asked to step in.
Really, I want to stress that last point. If we are creating a new
conference for contributors, we need to give new contributors an
opportunity to contribute. By not scheduling completely around the
relatively small number of us that are involved in multiple areas, we
create opportunities for others to help in attending and recapping
sessions.
> > Once all of these proposals are submitted, there would be a
selection
> > process to decide which of these would become part of the next flock. This
> > could be a mixture of voting and selection committee like this time or it
> > could be very different. The selection committee would likely also take
> > a look at whether any session was grossly underestimating who needs to be
> > present or overestimating what they could accomplish in the course of
> > a flock. Perhaps voting only applies to talks (which are not listed under
> > this idea as they are about impartng knowledge rather than getting something
> > done). The committee would likely need an ordered list of sessions because
> > of the next step:
>
> I think you're making this entirely too complicated. If you want to
> Do stuff, then go Do it. What is preventing that from happening on
> the 4th day of the conference? Please don't make me quote an old Nike
> ad slogan here... the output of any conference attended anywhere is
> dependent entirely upon the attendees of the conference going and
> doing stuff.
This has never worked out well at FUDCon. Using FUDCon Blacksburg as an
example, I had about five things I planned on working on with about fifteen
people in the infrastructure and packaging communities. I ended up starting
to discuss about three things with infrastructure people and spending
the other hackfest day in a face-to-face Board Meeting.
You are clearly overbooked.
Knowing what groups of people are needed lets you plan ahead of time
for the
amount of work that you can actually accomplish and the people you are
actually going to be able to talk to.
See above about emailing.
I think, though, that if we're serious about making flock into a
very
productive Do-Con, we need to consider these conflicts in scheduling as
problems and think about ways to address them when planning the next flock.
See above about emailing now.
> > this are a way for people to announce what they're
working on and where.
> > That way if I am able to attend for three days and I have a scheduled
> > discussion on the first and third days, I can participate in something ad
> > hoc on the day in between. It also allows people who didn't make the cut
> > for a scheduled hackfest to still get together with other interested people
> > and get some work done.
> >
> > Ideas for communication: Corkboards divided into time slots and open rooms.
> > Index cards for people to write down when they'll be in which room.
> > Thumbtacks to put them on the board. With our limited space, we'll want to
> > remember that there needs to be room for multiple cards in each room-time
> > slot.
>
> This sounds... sub-optimal. Just talk to the flock organizers and we
> can schedule whatever you want in a room on the 4th day and put it on
> the schedule.
>
That could be worked with. But to be clear, this is what you're signing up
the flock organizers for:
* I have an hour when none of the talks are interesting. relrod and I go to
the common hack room and start hacking on one-time-password integration.
I need a flock organizer to be available in the common room for me to tell
them to please publish the fact that we're working on otp in
infrastructure coding right now.
* The Updated Python Guidelines discussion have lasted longer than the
alloted time and spawned a neat subtopic that five of us want to explore.
We decide to meet in the common hack room to talk about it some more on
the 4th day. We need a flock organizer to be able to schedule us into
a slot on the fourth day.
* I don't see anything on the schedule for the next talk period so I wander
down to the common hack room to find something interesting. Either
internet is bad at the conference or I don't want to get out my laptop.
I need to see something that tells me what groups have posted that they're
working on things in the room right now.
So sure, a corkboard isn't great but what it does have going for it is:
* driven by the people who want to do something, no middle man.
* Immediately works
* has a presence in physical reality
A flock organizer can take the place of the corkboard but they'll need to be
physically staffing the location, taking information about what people are
doing and then entering it into both the physical and electronic locations.
There's also IRC. I'm sure we'll have a #flock-staff channel or
something running that will be manned the entire time. Anyway, I
don't believe what you suggest is beyond what the staff already
planned on doing.
josh