Creation of FAD components on FUDCon track

[Igor Pires Soares]

Em Qui, 2011-06-23 às 14:08 -0400, Paul W. Frields escreveu:
> 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.

Sounds good to me, specially for events that we organize Fedora
participation every year. This is something that can be discussed by
FAmSCo and the larger ambassadors group.

> > > 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 think that the allowable budget is not that clear at first, but it
will become clearer if FAD organizers get used to describe the costs in
the wiki.

> * 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.

The current documentation covers properly this point, once the budget
becomes clear. So we are good here.

> * 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'm not quite sure if this one is clear on the current FAD
documentation. For instance, I can't see how much money we have
available for this and next quarters specifically for FADs. We have
general budget availability on the Community Architecture expenses wiki
page, but nothing specifically for FADs.

> * 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).

That is also well explained on the current documentation.

> * 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

+1
Blog posts, an announcement on the appropriated lists, and a proper wiki
page should be enough to communicate it well.

> 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.

I see that a ticketing system for larger events might help, whether or
not we a have a FAD attached to them. For FADs, specifically, I think
that you covered it all here. It seems to me that the most important
issues are the budget availability information and the proper
communication that should be more documented on the FAD wiki.

-- 
Igor Pires Soares
Fedora Ambassador (Brazil) - Member of FAmSCo
Fedora I18N/L10N QA
https://fedoraproject.org/wiki/User:Igor