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.
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.
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.
> = Idea
>
> I thnk the core feature of FADs that we should try to adopt is the idea of
> groups. Instead of asking for individually hosted workshops, discussions,
> and hackfests we should ask for groups of people to host those. Similar to
> FADs, the groups need to identify what people are necessary in order to
> do something specific with that sessioni and how much time they want. An
> example for each of those categories:
>
> * 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?
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.
But with the current information that includes only the speaker, not the
group necessary to effect action, there's no way to know this.
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.
> 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.
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.
> The committee next needs to schedule them. They would need to
take everyone
> needed for the session to occur to attempt to fit them all together. If
> they run into places where they can't help but conflict they would need to
> choose a session to get rid of and select a replacement from their list.
When creating the current schedule, the committee actually tried very
hard to ensure that people with overlapping interests didn't have
conflicts. We then made adjustments based on reasonable requests to
further help that. if there are remaining conflicts, then it is
entirely reasonable within the current structure and schedule of flock
to suggest tweaks or even propose adjustments in speakers on a topic.
I availed myself of the tweaking process. I'm not saying that the committee
is doing a bad job here. I'm just saying that the procedure we're operating
on is not adequate for the problem space and we should be thinking of ways
to change the procedure for next time. To keep using myself as an example,
I only asked for tweaks to be made in one case where I felt it was essential
for me to be present at two sessions that would have otherwise happened at
the same time. However, there are numerous other working sessions where it
would be anywhere from interesting to extremely helpful if I was present.
Fedora Crystal Ball: helpful
Making Fedora Python3 ready: essential
Highly available Databases: Extremely helpful
Fedora release engineering: helpful
Fedora Mobile Apps: interesting
Fedora revamp: Next Steps: helpful
Document your code: Interesting
Hyperkitty hackfest: interesting to helpful
DOAP in Fedora-packages: helpful
OAuth: Essential
Dataviewer hackfest: interesting
Task automation hackfest: interesting
The totally new Fedora Changes Process: helpful
rebase you git!: interesting (I admit, even though I've used it for years,
I'm still a newb)
Pkgdb2: Extremely helpful
Bodhi2 Hackfest: helpful
fedocal: helpful
Updated Python Guidelines: essential
I'm not going to ask for tweaks to allow me to attend all of those or even
all the helpful ones for several reasons:
* It's selfish. Without more information, I can't know that my changes
aren't only applicable to me. So I can now attend both Databases and
Fedora revamp. But perhaps that means notting can't attend Release
Engineering and Fedora Revamp.
* It's not possible to do it all: There's six time slots. I have 11
sessions that I list as helpful or greater.
* Like you, I'm willing to just leave some things to chance since that's the
traditional FUDCon way.... ie: Maybe notting will go to Fedora Revamp and
help in crafting a sensible proposal. Maybe sgallagh will be happy to
give a summary of his Crystal Ball session at the next FESCo meeting.
etc.
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.
> === "Free-form" hackfests
>
> There should be the option for "free-form hackfests" as well. Essentials
of
There is. All day on the 4th day.
<nod> I'm not saying that flock doesn't do this (or other things in
the
proposal). I'm mentioning it as my proposal kinda throws out a lot of what
we're doing at FUDCon and this flock and I wanted people to know that this
isn't something to discard.
> 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.
-Toshio