Creation of FAD components on FUDCon track

[Paul W. Frields]

On Tue, Jun 21, 2011 at 10:26:11PM -0300, Igor Pires Soares wrote:
> Em Ter, 2011-06-21 às 14:42 -0400, Paul W. Frields escreveu:
> > On Tue, Jun 21, 2011 at 03:22:04PM -0300, Igor Pires Soares wrote:
> > > 
> > > For planning a FUDCon we have tickets that are open to anyone who wants
> > > to see them. We use them for tasks, costs and travel subsidies. For
> > > planning a FAD we need to file basically the same kind of tickets. Since
> > > there isn't a specific trac system or component for FADs, most of the
> > > tickets go to the FAmsCo track. Since the visibility there is more
> > > restricted, for understandable reasons, it takes some additional efforts
> > > to provide the same information for all interested in the FAD.
> > > 
> > > For instance, while planning the upcoming FAD at FISL we needed to
> > > replicate the same information available on FAmSCo Track also on this
> > > list and on the Brazilian mailing list. In addition to that, when
> > > mentioning a particular ticket, sometimes we would like to make clear
> > > what the ticket content is. And this is hard to do if the ticket is not
> > > visible to everyone.
> > > 
> > > Another approach could be to set up the regional ticketing systems to
> > > send email notifications to this list when planning the FAD, but I'm not
> > > sure if this will work due to the language diversity.
> > 
> > I guess I'm wondering why we need ticketing for FADs -- it seems very
> > much out of alignment with their mission to be lightweight, easy to
> > put together, inexpensive, and focused in a specific geographic area.
> > 
> > I'm 100% in favor of transparency in planning.  At the same time, I
> > think it's important that FAD event planning be very lightweight.
> > That's different from FUDCon events, which involve a lot more people
> > and a lot more funding.  A FAD is designed to bring people together
> > who are already in close proximity to each other, or can get together
> > with a relatively small amount of funding.  It's designed to require
> > very little formal planning and budget, and have a very tightly
> > focused goal of getting a specific piece of Fedora related work
> > completed.  For example, you might have three people on the
> > Infrastructure team who are interested in doing a hackfest to address
> > a set of bugs in the Fedora Account System code.  Or you might have
> > four people involved in the Design team who are getting together to
> > create a set of designs for a new set of configuration tools in
> > Fedora.
> 
> 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.

> > I've generally planned FADs entirely on the wiki, which provides
> > plenty of transparency when combined with discussion on the relevant
> > email list, and blog posts explaining the event.  Ticket filing seems
> > like overkill for these events, other than perhaps making a request
> > for the small amount of total funding needed (e.g. a hotel room or
> > two, and some reasonable food costs such as pizza during the event).
> > Typically the people who attend are self-organizing because they're
> > already interested in finishing work on the topic in question.
> > 
> > Regardless of how FAmSCo's Trac works, it should still be simple to
> > discuss the FAD on the appropriate mailing list, and/or announce it on
> > a Fedora Planet blog post.  If the FAD has an appropriate scope and
> > focus, and it's communicated openly, the number of people involved
> > will be pretty small, and people who aren't attending won't be worried
> > about transparency issues.
> 
> 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?

> Other issue we hit from the very begging was to figure out how much
> money was appropriate to spend on the FAD. I see that only a few FAD
> pages have a description of how much was spent. Fortunately, Robyn
> already provided us the right guidance, as also advised on the FAD wiki
> template, to include those descriptions and I think they will be helpful
> for next organizers.

Yes, FAD wiki pages should clearly indicate the budget, and what is
being spent.  That's simple to fix -- to get the costs approved,
simply require that it be so! :-) We're not talking about large
amounts of money.  Most FADs should be no more than $1K-2K.

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

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