Creation of FAD components on FUDCon track

[Paul W. Frields]

On Thu, Jun 23, 2011 at 12:23:39PM -0300, Igor Pires Soares wrote:
> Em Qua, 2011-06-22 às 16:40 -0400, Paul W. Frields escreveu:
> > On Tue, Jun 21, 2011 at 10:26:11PM -0300, Igor Pires Soares wrote:
> > > I do believe that FADs should follow that lightweight approach, and I
> > > see that this have been working pretty well. On the other hand, I see
> > > that the lightweight approach works better for standalone FADs. But FADs
> > > organized together with other big events such FISL can draw a lot of
> > > attention and demand some additional work. Not only because the FAD
> > > itself, but due to the characteristics of those events. Separating the
> > > FAD organization of the event organization itself might be
> > > counterproductive as well, since it usually involves the same set of
> > > people, activities and resources.
> > 
> > It makes sense to keep some of the work of FAD organization together
> > with the event at which it happens.  As far as I know, though, we
> > don't arrange event organization using the fudcon-planning Trac
> > either.  I still don't understand clearly the problem we're trying to
> > solve here, and this solution seems like it would confuse people as to
> > what level of work is required for any FAD in general.
> 
> Yes, we don't arrange event organization using the fudcon-planning trac
> but IMHO would be nice if we start doing it. That might not be necessary
> for all events, but for major events that would be helpful. If the event
> is supposed to host one or more FADs a ticket could be opened for them.
> This is just an ideia and I see that event organizers might want to deal
> with it differently, depending of the event.

I guess I could see using a Trac for larger events, if that is what
Ambassadors and other event planners agree on.  However, if indeed
people agree they want to use an issue tracker, I'd like to see that
be separate from the one for FUDCon.  The groups of people interacting
with these event plans, and the kinds of tasks they do, are
significantly different, and the "large event planning" instance
probably needs to be set up differently to accommodate their workflow.

But stepping back to speak in more general terms... I'll write some
more below.

> > > I'm not sure if the wiki is the best place for some specific details
> > > such reimbursements needed, airfare itinerary discussions, etc. It's
> > > hard do keep all those things on the wiki. People can erase some
> > > information by mistake and the organizational history doesn't appear
> > > quite clear as in a ticketing system.
> > 
> > Wiki erasures are pretty rare, and easily fixed, and again, if the
> > event is supposed to be lightweight, I would think that organizational
> > history would be less of a concern.  If the purpose is to make it
> > easier to plan a FAD, shouldn't we just fix the FAD wiki page to
> > address that?
> 
> Certainly, adding some more information to the FAD wiki page would help.
> For instance recommendations to write blog posts, before and after the
> event, and to use the appropriated mailing lists to announce it (this
> list and a specific one related to the FAD purpose). I know this is a
> recommendation for all events, but won't be bad to reinforce it.
> 
> More important than that, the FAD wiki page needs to be translated. I do
> believe that FAD organization process is transparent, but it needs a few
> tweaks to not only be transparent but to look transparent to all. IMHO
> translations would help to address that. They would help to avoid
> misinterpretation about the organizational process and also provide
> easier information for a larger group of people. This is something we
> need to work on together with regional communities and I'll keep that in
> mind.
> 
> > > I just realized that the upcoming FAD at FISL will be the first FAD in
> > > LATAM, although we have had really nice Fedora activities at FISL
> > > before. I'm not going to attend this year but I'm working on the budget
> > > side along with FAmSCo, and I would like to provide proper guidance for
> > > LATAM folks and improve the process for the upcoming FAD and next ones.
> > 
> > I think it's fantastic that you're willing to do that, Igor!  I still
> > think setting up a bunch more process for FADs, or raising the level
> > of organizational work required, is not the right direction to go.
> > But perhaps you could start by helping us identify where the current
> > FAD setup pages are missing, or unclear, so we can fix them?
> > 
> > Again, just my $0.02 and I thank you for being very thoughtful about
> > the discussion!
> 
> Thanks for engaging in this thread, Paul!. At first I was just
> brainstorming here, but I see that this conversation already provided
> some good concrete ideas we can work on. :)

One of the things I continue to be concerned about is the amount of
process built up around doing good things for Fedora.  Obviously we
all need to communicate well with each other to be efficient and
effective.  It seems like in the past we haven't needed a lot of
ticket tracking to do that.  But at the same time, the size of the
community working together has increased -- and maybe that requires
this type of level of organization for big events like a FISL or a
FOSDEM.

At the same time, we need to separate how we do organizational
tracking of big events from what we require at a minimum for small
gatherings like FADs.  And underlying all of that, we need to ensure
that we aren't making people block on a difficult process to get
things done.  And we need to communicate that to all parts of the
Fedora community, in all parts of the world, so that people are moving
ahead with events, and not always waiting for permission from someone.

The process for most FADs should be very simple, and anyone in ANY
region of the world should be able to follow it.  For instance, if I
want to put on a FAD, I should be able to go through the following
steps very easily.

* Start at the FAD page on the wiki, to understand what's an
  appropriate reason to put one together.  I should be able to also
  easily see what an allowable budget is for a FAD, say $1K-2.5K.

* I should consult with the people who want to get together for the
  event, to make sure we agree on the time and location.  The people
  and location should be tailored so the event fits into the budget,
  and can meet the goals we've set up.

* I should be able to see how much in each Red Hat fiscal quarter is
  available for all FADs, and I should be able to see who has already
  committed money for a FAD.  For example, I should be able to see
  that we have $20K to put on FADs for the quarter, and that there are
  five (5) FADs already scheduled that commit an estimated total of,
  say, $10K.  That means if I want to put mine on, I know there's
  money available for it.  I shouldn't have to wait for anyone to tell
  me so, I simply sign up for it.  (Notice how this encourages
  documentation -- if I'm not signed up, I can't expect any money or
  reimbursement!)

* I should be able to gather people and make plans, based on that
  budget.  I can use that budget to book hotel rooms, plan to cover
  some reasonable food expenses for the small number of people
  attending, and so forth.  If train or air fare is required, I can
  handle that too (always sticking to the budget).

* As I make these plans, I should announce what I'm doing on the
  appropriate lists, and post a blog on the Fedora Planet.  I should
  have a wiki page that shows what's being planned in detail, as with
  other FADs like this:
  http://fedoraproject.org/wiki/Etherpad_FAD
  http://fedoraproject.org/wiki/FAD_Fedora_Talk_2009

As you're working up more ideas, I would offer that we want to keep
pursuing something close to the above.  We all want easy access for
all contributors to put on FAD events that get real work done in
Fedora on a "sprint" basis.  That makes FADs special and different
from other important gatherings such as an event booth, a FUDCon, or
an end-user focused teaching session.

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com