Creation of FAD components on FUDCon track

[Paul W. Frields]

On Tue, Jun 21, 2011 at 03:22:04PM -0300, Igor Pires Soares wrote:
> Em Ter, 2011-06-21 às 10:06 -0400, Paul W. Frields escreveu:
> > On Mon, Jun 20, 2011 at 03:11:16PM -0300, Igor Pires Soares wrote:
> > > Hello all,
> > > 
> > > I would like to suggest that we create components for future FADs on
> > > FUDCon Track the same way we do for FUDCons. That way we could file
> > > organizational and subsidy tickets there.
> > > 
> > > Due to private financial content and privacy reasons, the visibility of
> > > FAmSCo track is restricted, and unfortunately, people use that as an
> > > excuse to claim lack of transparency since they can't view others
> > > tickets, although we discuss tickets content in public.
> > > 
> > > The tickets procedures used for FUDCon didn't prevent people from
> > > complain before but I think it is a good example to follow.
> > 
> > I'm not sure I understand the link between FAD planning and the
> > privacy of the FAmSCo trac.  Can you be a little more specific, Igor?
> 
> 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'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.

If there are too many people interested and involved to keep the
budget small, then perhaps the purpose and scope of the FAD should be
reconsidered.  In other words, is the topic something that really
should be done through discussion on the list and in public IRC
meetings instead.  The harder or more burdensome it gets to plan a
FAD, the more I worry that fewer will likely happen.  IMHO FADs
shouldn't need the additional administrative overhead of large event
(e.g. FUDCon) planning, as long as they have:

* A clear purpose, such as "Fix this list of bugs," "Produce a
  system design for $TASK," or "Complete all packaging for a <FOO>
  toolchain in Fedora."

* A small scope, focused on doing measurable work, with a reasonable
  chance of being *finished* by the time the FAD is over.

* A small set of interested and involved Fedora contributors who can
  gather rather inexpensively to accomplish the task.

Of course, this is all just my $0.02 as a sometimes FAD attendee and
organizer.

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