Fedora Board Recap 2011-01-24 (FESCo Goals IRC meeting)

Mon Jan 24 21:20:12 UTC 2011

(These notes are available on the wiki at the following URL:
https://fedoraproject.org/wiki/Meeting:Board_meeting_2011-01-24 )

= Fedora Board Meeting, 2011 01 24 =

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

== Attendance ==
'''Present:'''
* 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)

== Agenda ==
* Fedora strategic goals discussion with FESCo

== Notes/Summary ==

=== Fedora strategic goals discussion with FESCo Overview ===
* the goals FESCo agreed on can be found in FESCo trac ---
https://fedorahosted.org/fesco/ticket/53
* FESCo picked their top three goals, but also ranked 9 of the 15 goals
in preferential order:
*# (Goal #1) Improve and simplify collaboration in the Fedora Community
('''7 votes''')
*# (Goal #3) Improve and encourage high-quality communication in the
Fedora Community ('''7 votes''')
*# (Goal #15) Improve Fedora developer experience ('''4 votes''')
*# (Goal #12) Improve education & skill sharing in community ('''3
votes''')
*# (Goal #14) Evaluate late-breaking technologies for
inclusion/interaction with Fedora ('''3 votes''')
*# (Goal #4) It is extraordinarily easy to join the Fedora community and
quickly find a project to work on. ('''3 votes''')
*# (Goal #5) Recruiting new / less-common skillsets into the project
(e.g., project managers, designers) ('''1 vote''')
*# (Goal #7) Encourage open standards ('''1 vote''')
*# (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 -
http://mairin.wordpress.com/2010/03/16/a-rich-web-interface-for-mailing-lists/

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 repos.fedorapeople.org 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 ==
*
[http://meetbot.fedoraproject.org/fedora-board-meeting/2011-01-24/fedora-board.2011-01-24-19.01.log.html Full IRC log text]
*
[http://meetbot.fedoraproject.org/fedora-board-meeting/2011-01-24/fedora-board.2011-01-24-19.01.html Meetbot summary]

~m