From Fedora Project Wiki

Fedora Board Meeting, 2011 01 24

  • Secretary: Jaroslav Reznik (jreznik) and Máirín Duffy (mizmo)
  • Meeting Type: IRC



  • Jaroslav Reznik (jreznik)
  • Toshio Kurotami (abadger1999)
  • Tom 'spot' Callaway (spot)
  • Jon Stanley (jds2001)
  • Rex Dieter (rdieter)
  • Máirín Duffy (mizmo)
  • David Nalley (ke4qqq)

FESCO representatives:

  • Kevin Fenzi (nirik)
  • Bill Nottingham (notting)
  • Marcela Mašláňová (mmaslano)
  • Christoph Wickert (cwickert)

Not Present:

  • Jared Smith (jsmith)
  • Stephen Smoogen (smooge)
  • Joerg Simon (kital)


  • Fedora strategic goals discussion with FESCo


Fedora strategic goals discussion with FESCo Overview

  • the goals FESCo agreed on can be found in FESCo trac ---
  • FESCo picked their top three goals, but also ranked 9 of the 15 goals in preferential order:
    1. (Goal #1) Improve and simplify collaboration in the Fedora Community (7 votes)
    2. (Goal #3) Improve and encourage high-quality communication in the Fedora Community (7 votes)
    3. (Goal #15) Improve Fedora developer experience (4 votes)
    4. (Goal #12) Improve education & skill sharing in community (3 votes)
    5. (Goal #14) Evaluate late-breaking technologies for inclusion/interaction with Fedora (3 votes)
    6. (Goal #4) It is extraordinarily easy to join the Fedora community and quickly find a project to work on. (3 votes)
    7. (Goal #5) Recruiting new / less-common skillsets into the project (e.g., project managers, designers) (1 vote)
    8. (Goal #7) Encourage open standards (1 vote)
    9. (Goal #9) Get more involved with upstream / sidestream FLOSS Communities (1 vote)
  • No votes for:
    • GOAL #2: Provide infrastructure to help people control their content and devices
    • GOAL #6: "Access from Anywhere" strategy
    • GOAL #8: Improve remote real-time & high-bandwidth collaboration
    • GOAL #10: Improve awareness and utilization of available Fedora community resources
    • GOAL #11: Expand global presence of Fedora among users & contributors
    • GOAL #13: Sharing responsibilities (mentorship, documentation of tasks / SOPs, sharing skills)

GOAL #1: Improve and simplify collaboration in the Fedora Community

FESCo's ideas for working towards this goal:

  • look at our unresponsive maintainer policies again... we should really encourage co-maintainers more so packages don't sit with no one watching them.
  • how to possibly improve our morass of mailing lists
  • how to possibly reduce the number of irc channels/lists/etc to make it easier for people to join/follow
  • encourage direct communication between different groups. recently things seem to go up all the way to the board and then down again. this is ineffective collaboration. we need to have workflows for $contributor from group A requesting something from group B. ether there are not workflows or they are all different
  • As mentioned on the board wiki, calendaring and scheduling could really be improved.
  • it would be great to know when/where things are happing all the time.
  • I wonder if we couldn't designate or create some area in all the communications channels for pointing people at just where to go for something. some kind of directory service... so you could look up who you ask about helping out with $foo instead of just wandering around trying to find out.
  • say all groups have a trac instance to bring something up to their attention, just like the board opened it's trac recently. doesn't need to be trac, but a common protocol for everybody

GOAL #3: Improve and encourage high-quality communication in the Fedora Community

Nirik noted there is some overlap between practical application of this goal and goal #1. But FESCo ideas for making it happen:

  • Teaching folks how to run meetings, and how to communicate better on lists would be lovely.
  • We could possibly use some framework like moodle to setup classes for these things so people could learn more easily.
  • Possibly we could ask mailing list owners to try and get people to avoid long threads or off topic discussion, but there's no easy fix
  • empower mailing list owners to do more management when needed. Possibly the Community Working group could propose some ideas on how they could better do so, but I think it might be better seen when coming from people who are part of whatever area that is and are managers of that resource

When asked what the number one place where communication breakdown occurs was, both nirik and notting said mailing lists:

  • the biggest communication breakdown place. Some people just use lists and not other channels. Issues getting IRC discussions synched back to list. Issues with noise on the lists. (nirik)
  • spot says there are some crazy ideas on how to accomplish things to improve signal to noise ratio on mailing lists without acting like hall monitors
  • nirik cites mizmo's mailing list ui design idea -

Hall-monitor / educational style solutions aren't viable, though:

  • Anything that is described as 'teaching people how to communicate better on mailing lists' sounds like it would trigger a backlash, however well intentioned. "who are you to tell me i can't communicate?" etc. alas. it sounds like hall monitor. You can teach people better communication, but I'm not sure that those who go OT will be in this class
  • mmaslano thinks it's like hall monitor - people who are OT usually don't participate classes to become better ones

GOAL #15: Improve developer experience

Ideas from FESCo on working towards this goal:

  • gather feedback from developers at fudcon on areas to look at improving.
  • get more people doing buildroot overrides or some way to automate them.
  • See if we can reduce the maintainer sponsorship queue down. (so people wanting to help are there to help all of us)
  • make co-maintainers more common/expected. Possibly by auto acking requests to be a comaintainer if the maintainer doesn't respond or the like.
  • help improve or kopers or whatever so they are easier for our maintainers to use.
  • support of groups of maintainers in SIG or on group of packages.
  • fesco could look at doing would be some better way to get provenpackagers helping others... some bat signal to call for help on a serious/difficult bug they can't solve.
  • better communication with bugzappers would be nice. I think they could help more packages, but it seems sometimes packagers don't know to ask for them to help
  • we cant force people to do things, but one thing that might improve some of those bottlenecks is having multiple people who do each thing/can do tasks for some team... that way there's no single point if someone is busy or the like
  • ke4qqq to get with releng and document instructions how to join the team and put a wiki page up

FESCo noted there's a lot in these ideas they can't actually do, though:

  • there's little we can do to enact new initiatives other than 'set policies'

Another issue:

  • we don't necessarily have project-wide roadmaps for the tools we use

Next Meeting

Next meeting will be (IRC or phone) on 2011-01-31 at FUDcon Tempe.

Full IRC Log