= 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.
= History
In the past we've funded two primary types of events: FUDCons and FADs.
FUDCons are conferenc-y events with a whole day (a quarter to a third of the
planned event time) devoted to talks -- something that is directed at
conveying information of things that have already been achieved to others.
People come as individuals. They give presentations as individuals. And as
individuals, they choose which hackfests they are going to spend their time
participating in. As individuals, they also decide when they're going to
arrive and when they're going to leave (with some only coming for the talks
or leaving a day early or cutting into their final day with travel plans).
FADs, on the other hand, are about small groups of people. The participants
have decided ahead of time which people are needed and going to attend.
They've decided what goals they are going to try to achieve as a group.
They have dfinitive dates that everyone will be in attendance. They may
even have had discussions ahead of time that have laid out who is going to
be working on what subtask.
In order to achieve the Do-Con vision, I think it makes sense to take
a little more from the FADs and mix it with the FUDCon basis that we already
have.
= 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.
* Discussion on Changing the Fedora Release Process: (two half day sessions.
Please do not schedule on the same day) Need at least one person from
rel-eng, three people from FESCo, one person from the Board, one person
from FPC. A few other well known packagers so we aren't making plans for
things that won't fly with the general packager community. The goals:
(1) evaluate the current posibilities (links to he proposals).
(2) Try to mix the best features from all the proposals to come up with
one or two strawmen that can be taken to the mailing lists for comment.
* Hackfest to add openid support to all Fedora Infrastructure applications:
(Quarter day session) This would need the author of the fas_openid
implementation for Fedora, one of the python-fedora maintainers, one of
the leaders of each of the infrastructure applications to be ported,
someone familiar with FAS, someone who is familiar with the authentication
layers of each web framework the applications use, and at least one person
familiar with deploying these things in infrastructure. (Note: overlap
between these roles is perfectly fine). The goals:
(1) Code written so that each application uses fas_openid for
authentication.
(2) Deployed into infrastructure's staging environment.
(3) Authentication adapters for openid with the fedora extensions for each
web framework merged into python-fedora
The actual proposals would include the names of people who would fulfill
each of the necessary roles.
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:
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.
== Some other things to think about:
* Anyone can attend sessions. The necessary people are the people who must
be present but other people can join and add to the discussion, learn from
the workshop, and help with a hackfest.
=== "Free-form" hackfests
There should be the option for "free-form hackfests" as well. Essentials of
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 is all sounding very FADy... what can we take from FUDCon to keep
the good features of that?
In terms of benefit to a Do-Con style flock, I think that the FUDCon model has three
main things going for it:
* Save on travel expenses -- instead of flying people too and from multiple FADs
we're able to fly people to a single Flock and have them participate in
multiple meetings. This is already part of the idea above.
* Cross pollination -- having a large number of people together (for
instance, at FUDPUB) is often a way to encourage cross pollination. But
I think it would be great to put somethings explicitly into the schedule
to encourage talking between people in different sessions. I'm a fan of
having something at the very beginning as it serves several purposes:
- Identify people you want to talk to in one of the ad hoc times over the
course of the conference.
- Generates buzz about things that propogate to all of the conference not
just the people who attended the intro session. If there's
a user-focused section of flock I'd put this portion of the contributor
section before that. That way people will hear about things that were
discussed there.
- A pre-session can have several goals -- introduce people who are working
on certain domains, make decisions that are close enough to consensus
(for instance, if there had been mailing list discussion for some weeks
prior on the mailing lists), and clarify what specific groups are going
to accomplish at the conference.
- It has also been suggested that we have short reporting-type meetings
every day. This subgroup discussed this, decided that, or implemented
this other thing. The good side of this is people at the conference
will know what's being accomplished over the course of the conference.
The drawback that I see is to keep it short, we'd probably have to
limit to reporting only whereas the benefit of having many people
together is that they can all give input. It might be better to have
a day in the middle where people talk about what they've accomplished so
far and get input from the other contributors as feedback and ideas for
going further.
* Turn users into contributors -- So let's bring talks back into this
discussion. Talks seem like the major factor for bringing users to the
conference. Talks are also interesting to contributors (contributors are
users too). Talks are mostly about reporting information on things
already accomplished or tips and strategies for more effectively using
things that are already present in the operating system. FUDCon had
a plethora of talks but I think this year's flock is doing several things
to try and make the talks better for pulling in users and making them
contributors:
- Moving to pre-selected talks. This lets users know what's slated to be
discussed and show up based on the talks (and speakers).
- Moving to having start of day talks followed by end-of-day workshops and
hackfests. -- I'm not sure how well this will work out for the
contributors trying to get work done at the hackfests but it seems like
a good experiment to get users to participate in contributor sessions.
Let's see how it goes.
-Toshio
