11:37 a.m.
= 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
12:31 p.m.
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.
= 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?
* 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.
Again, a representative set of people will be there to accomplish this.
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.
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.
=== "Free-form" hackfests
There should be the option for "free-form hackfests" as well. Essentials of
There is. All day on the 4th day.
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.
josh
2 p.m.
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
2:04 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/25/2013 03:00 PM, Toshio Kuratomi wrote:
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.
I imagine the staff folks will be doing this sort of thing anyways. :)
~tom
==
Fedora Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlHJ6bMACgkQPF6ZrZMFQmCwNgCeIgsYTrQUZYKVVCSemAbpJg7E
rXYAn04SRq9YNxDbmnAO+kMLh9ibsd22
=XALX
-----END PGP SIGNATURE-----
2:15 p.m.
I have been to plenty of conferences where in most time slots I had the
world's hardest time deciding between sessions but inevitably one where I
wasn't interested in anything. Wanting to be everywhere at once is a sign
it's highly relevant.
I suspect that while the conflicts will be true for a good number of
people, as we have quite a few who are highly involved like you, Toshio,
that it's also probably the exception not the rule to feel you /need/ to be
in so many places at once.
Maybe the solution is to work within the teams. For example, during an
upcoming FESCo meeting, discuss whom will be there and how you can most
efficiently split your time among sessions where you think there should be
FESCo representation.
If there's something useful we can do to amend the schedule this time
around, let's talk about what that is in concrete terms. If it's just "this
could be useful next time," let's talk about it on August 14. We've got
enough to worry about for Flock 2013 without trying to start 2014 until
it's over!
Ruth
3 p.m.
On Tue, Jun 25, 2013 at 03:15:32PM -0400, Ruth Suehle wrote:
If there's something useful we can do to amend the schedule this time around,
let's talk about what that is in concrete terms. If it's just "this could
be
useful next time," let's talk about it on August 14. We've got enough to
worry
about for Flock 2013 without trying to start 2014 until it's over!
<nod> My intention was just to put down thoughts for future flocks -- not
to derail the planning for the current flock :-) We can definitely get back
to all of this once we're back from flock 2013 :-)
-Toshio
7:51 a.m.
Hello all.
I have been mostly quiet trying to help and doing my best to make my small
part of this responsibility work; however i do have some thoughts i would
like to share.
1.- About Conference Schedule: No; there is no way the schedule, not this
year and neither next ones; will fulfill every one expectations. Main
reason is that even if we are trying to do a DO-Con, we are trying to work
with 8 different teams. Truth is that at least 70% of us work with more
than one team. Not FEsCo, not Board, not even organizers will be able to
manage a perfect schedule while having so many rooms.
Ideas for this:
* While more rooms, less probabilities of attend to your preferred talks.
* Next time we could try to have at least 1 empty room all day only for
meetings of those people who couldn't see each other at talks or for random
purpose meeting (no, not a room for hacking, an extra empty room that can
be used for 45min or 2hours period)
2.- About Event Overall: Everyone has this huge expectations on what a
DO-Con is but there is NO way we can have both worlds on it. You either
consider the developers and "Doers" or you consider the full community,
which includes people that watch talks but doesn't do anything. A
successful Doers conference can't be this "super mega huge" event because
Number 1 rule to let people Do is to not distract them and don't make them
run into different rooms every 45min.
* You either let the world know about how awesome Fedora is, or you give
them time to work and make Fedora that awesome.
What I think is that in this pursuit of being bigger than other commercial
USA events, we have a lack of attention into the small details that make
contributors do their work at this gatherings.
What do I think we should do? Stop trying to conquer the world at a main
event and start focusing into teams. We have FADs, which are small events
that clearly bring new contributions into Fedora; Why don't we try to
recruit everyone everywhere? I just see that in this need of bigger
attention, this kind of events will only reinforce the actual contributors
but not the new and potential ones, and remember, the number of Fedora
contributors that works for RH isn't as big as the number of contributors
that have their own life and responsibilities; which means that the 60/70%
of the non RH contributors will eventually vanish; so we are talking that
we constantly need to be recruiting people that is able to do the Fedora
work.
Now I'm wondering; why don't we spend this enormous amount of money and
time into make smaller events everywhere; no FUDcons, not FADs, more like
hackfest days, Do-days, name it; and gather those teams that need at least
2/3 days lock inside a room to develop and fix parts of Fedora that truly
need attention?
Conferences are places to spread what we do and to recruit people; if you
don't give people a bit of freedom inside this events, at the end, they
will be so busy trying to attend to so many talks that at the 4th day, they
won't have develop or write a single line of code.
People making decisions needs to stop a bit, read what their community has
to say, and act based on that. So please, instead trying to find solutions
into corporate events, try to look down to your community and listen to
what they have to say; Fedora isn't a company, is a community, and if I'm
wrong, please excuse my words and move on.
Sorry for the long mail :)
2013/6/25 Toshio Kuratomi <a.badger(a)gmail.com>
On Tue, Jun 25, 2013 at 03:15:32PM -0400, Ruth Suehle wrote:
>
> If there's something useful we can do to amend the schedule this time
around,
> let's talk about what that is in concrete terms. If it's just "this
could be
> useful next time," let's talk about it on August 14. We've got enough
to
worry
> about for Flock 2013 without trying to start 2014 until it's over!
>
<nod> My intention was just to put down thoughts for future flocks -- not
to derail the planning for the current flock :-) We can definitely get
back
to all of this once we're back from flock 2013 :-)
-Toshio
_______________________________________________
flock-planning mailing list
flock-planning(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/flock-planning
--
tatica
Maria Gracia Leandro
http://www.tatica.org
http://fedoraproject.org/wiki/User:tatica
LinuxUser= 440285 GPG Public Key: E1CDCC56
2:19 p.m.
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
2:55 p.m.
On Tue, Jun 25, 2013 at 03:19:16PM -0400, Josh Boyer wrote:
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.
> 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 be clear, I'm not writing off flock. I'm pointing out that the vision
I heard about having a new conference was to try making a conference that
enabled more accomplishing of tasks rather than reporting, that some things
about how we planned this flock could be better for accomplishing tasks if
we looked at the FAD model and integrated some of the procedures and ideas
from that instead.
But, if you are talking about improving the current flock, my attitude is it
is what it is. I don't want to interrupt the current planning by asking for
too many changes for the current flock process. So I don't want to come
across as seeming to say "Hey, the schedule totally doesn't work for me, can
you make massive changes to accomodate my personal interests?" I'm just
trying to point out changes we could make to future flock planning so that
next flock would be even better.
If the committee really wants to try to put some of this into effect now,
I could bring this up at the fesco and infrastructure meetings and see who
we can list out people who are needed in order to discuss certain items on
our respective agendas. I'm not sure if that's what's desired though...
I think I'm getting mixed messages about whether that's something that we
want now or something that we want to discuss later (rsuehle's mail seems to
be to do it at or after flock :-)
> 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.
That really depends on what the vision is. If the vision is that things get
worked on and completed at this conference then you need to have all the
relevant current contributors. new contributors are a bonus.
If you want to get new contributors, then that's a different focus with
different needs. I'm just going off of what I remember of rbergeron's
original message on the Do-Con topic were (and who knows -- I might even be
misremembering those... I had the experience of Board phone calls in addition
to the public messages). It's totally fine if the focus is shifting, just
let me know that it has and I didn't realize it.
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.
Cool. Happy that we're all thinking along similar lines here.
And lastly:
You are clearly overbooked.
Yes.
:-)
-Toshio
3957
days inactive
3958
days old
flock-planning@lists.fedoraproject.org
8 comments
5 participants
participants (5)
-
Josh Boyer -
María Leandro -
Ruth Suehle -
Tom Callaway -
Toshio Kuratomi