Tying threads together.
In the past, Fedora, as a community, has had a large volume of debate
regarding the usability of Fedora. Including debating who our primary
audience is, how easy (or difficult) Fedora is to use, how much focus we
should invest in usability, if increased usability results in more
contributors, and if said increased usability diminishes our ability to
deliver forward-thinking, cutting-edge releases - Features, First.
I'm sorry to report that I will not be opening Pandora's Box today to
discuss the usability of Fedora the Distribution.
Instead, I'd like to focus on the usability of Fedora, the project, the
We have two threads right now that I'd like to tie together. One focuses
on the delicate balance of the Board's role as an enabler of progress in
the community, vs. the direction-pointer of progress in the community,
and whether or not the Board should be consulted for advice in various
matters, and if that leads to a precedent where the Board is essentially
giving permission to accomplish anything. The other focuses on several
problem areas that we have; starting with sponsorship of event
attendees, to FAD occurrence (or lack thereof), to Budget Crisis, and
other areas pointed out.
One of the Board's goals for the F16/F17 timeframe is: "It is
extraordinarily easy to join the Fedora Project."
I would argue that, right now, that it is Extraordinarily Difficult to
get anything DONE in the Fedora Project.
Max mentioned a phrase in a previous mail this week that I think is
incredibly applicable here: Institutional memory. Many of us have been
around a while; most of the previous respondents to these emails, far
longer than I have. Those folks participating and contributing to the
aforementioned threads, by and large, know that they can Go Forth and Do
without seeking board blessings; inherently know what resources are
available; more or less have a gut feeling on when they should or
shouldn't apply for funding for an international FUDCon; know who to ask
for resources; etc.
None of this is readily apparent to anyone who shows up on the
proverbial doorstep of the Fedora Community, wanting to actually do
something. Most people who do show up, of course, just want to
contribute in some way, but eventually, many of those folks move beyond
smaller contributions, and move into Bigger Things Territory.
* We do not boldly state that Contributors are Empowered to Do New
Things. We do not boldly state that the Board is not, or is, the
be-all-end-all point of asking permission.
* We do not list resources available in an obvious fashion. Unless you
know that FADs exist, almost nobody will ever think to ask for one.
* In the cases where people do know that resources are available,
particularly financial resources, a whole boatload of problems becomes
** Conflicting and confusing documentation as to how to obtain resources.
** Little to no documentation on who is allowed to ask.
** I won't even get into the Budget Situation. Too early.
* While some of the above may be insinuated in various places, it is not
spelled out, definitively, and obviously, to anyone who might want to do
* And in the cases where some processes are definitively spelled out -
they are often broken, or not working entirely. Spins, anyone?
While I largely agree with David's previously stated point of view that
the majority of power to direct or effect change in Fedora lies with the
people doing the work, I think that it is certainly in the Board's
interest to ensure that community members are enabled to actually get
the work done.
Institutional memory is not going to carry the Fedora project forever.
We are far larger of a community than we used to be, and far more
diverse, and in far more corners of the world, than we have ever been,
and we continue to grow. I would hope that most Board members hope to
never be on the Board again after they have served the time that they
wish to serve -- not because being on the Board is a horrible, torturous
experience, but because they want to see new contributors come into the
project, accomplish things, and become leaders in their own right.
Enabling accomplishment is what leads to people blossoming into leaders
-- and unless we make it incredibly obvious, and more permanently
stated, how one can accomplish things in Fedora, and work towards making
it EASY to get those things accomplished, we will be right where we are,
for a very long time, same people, same problems, same debates.
The Board shouldn't be a place of permission. I think it can be and
often is a place of advice, and idea-sharing, and problem-solving.
Advice shouldn't constitute blessing, and I think we are generally clear
on such things. However: if people don't know where to go, or who to
ask, or what they are allowed do in terms of accomplishing things, at
*best* they are going to be coming to the Board; the worst case is that
they move on and accomplish things elsewhere. I believe it is in the
Board's interest, and really, the community's interest, to ensure that
the Usability of Fedora the Project - is, and continues to be,
functional, or better yet, user-friendly. Which means taking a bit
more direction. In many cases, it means delegation to smaller groups to
fix specific problems, or stepping up in the absence of problem-solvers
and solving it. I don't think this is something that is heavy-handed of
the board, nor does it set the tone of direction for the project, or
give the impression that the Board is the group that you must come to
for anything; I simply see it as the Board, and anyone else who wants to
participate, really, taking a step in the right direction and enabling
people to more easily accomplish things.
The best way to NOT be a place of permission is to clearly state that
contributors are enabled, how they are enabled, and what resources they
have at their disposal, and make this place of information incredibly
easy to understand, well-known, and obvious to newcomers. And ensure
that the processes that back up the enablement are just as clear, or at
least, not broken, and have clear owners. And ultimately, make sure that
we are not a place simply of Institutional Memory and the Those Who Know
I think we, the Board, and the wider community, need to tune in the dial
a little bit and focus on usability of our community. It's not just
"joining the project" -- it's about thriving once you are in.
Anyone know if we're allowed to have a Project Usability FAD? :) (That
was a joke. Just to be clear.)
Thoughts welcomed. (Note: THIS EMAIL IS NOT A DIRECTIVE, just long-winded.)
advisory-board mailing list
Tying threads together.
On Wed, 2012-02-15 at 10:00 -0700, Robyn Bergeron wrote:
> The best way to NOT be a place of permission is to clearly state that
> contributors are enabled, how they are enabled, and what resources they
> have at their disposal, and make this place of information incredibly
> easy to understand, well-known, and obvious to newcomers. And ensure
> that the processes that back up the enablement are just as clear, or at
> least, not broken, and have clear owners. And ultimately, make sure that
> we are not a place simply of Institutional Memory and the Those Who Know
> How, Can.
> I think we, the Board, and the wider community, need to tune in the dial
> a little bit and focus on usability of our community. It's not just
> "joining the project" -- it's about thriving once you are in.
> Anyone know if we're allowed to have a Project Usability FAD? :) (That
> was a joke. Just to be clear.)
> Thoughts welcomed. (Note: THIS EMAIL IS NOT A DIRECTIVE, just long-winded.)
Three initiatives I believe will seriously up the level of project
- Fedora open badges (eg https://fedoraproject.org/wiki/Fedora_RPG from
early 2011 or more recently
Because if you set out specific tasks and define them well enough that
someone new to the project could pick them up, and enable them to
visibly watch their skillsets and progress in helping the project grow,
you're not only leading them to get valuable work done, you're also
motivating them and reminding them of the awesome things they've
accomplished. (The design team has seen evidence of this with the
manually-administered design ninja bounties)
- Fixing mailing lists for the love of all that is holy and even that
which is not (eg
http://blog.linuxgrrl.com/2010/03/16/a-rich-web-interface-for-mailing-lists/ ) so we can actually productively get work done.
- Collecting project statistics to figure out the overall health of the
project and identify which areas need the most care & feeding (I listed
this last because I think we know in heart-breaking detail the problems
to go ahead and start solving some NOW, and I wouldn't want us to be
stuck waiting on a stats platform to be built to tell us the same
things. Long tmer, though, this is a critically needed part of project
advisory-board mailing list
|All times are GMT. The time now is 05:53 PM.|
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.