Main questions
What is your take on the granting exceptions to Fedora packaging rules for Mozilla products in order to use their trademarks? For context, see the recent Thunderbird discussion on the devel list.
Bill Nottingham - FESCo
While it's not the ideal situation, I feel that we gain more by working closely with upstream on the Mozilla suite of products than we'd gain by forking the trademarks.
Bruno Wolff - FESCo
I don't think that packages controlled by trademarks should get permanent exceptions to our packaging rules. I think they need to have a plan to get rid of bundled libraries and to make sure there is a way to quickly apply patches when needed in Fedora. It seems in the particular case noted, there was a communication breakdown, but that in theory a patch could have been applied in reasonable amount of time. But it isn't clear that the causes for the breakdown is fixed.
Personally, I don't see a lot of value to Fedora to being able to use those trademarks and wouldn't have a problem with using alternate names for the packages. But marketing isn't my area of expertise and there is a possibility that dropping the trademarks could negatively effect the relationship between our packagers and upstream.
Justin Forbes - FESCo
While I may not agree with all of the limitations as they have been
interpreted (it seems silly that we would need approval for a patch already
accepted upstream), I do feel that the trademarks have value. Provided the
exceptions are not just completely unreasonable, they should be considered.
For this particular issue, I think it was mainly communication, and the
issue could have been handled a bit differently.
Kevin Fenzi - FESCo
I think that the trademarks are both good and bad. Good in that many
people know them and will be happy to see/use them on Fedora. Bad in
that in theory they could constrain our packages. In practice however,
I think we can just try and improve communication with the upstream
projects and end up with both a trademarked package from upstream and a
package in Fedora that meets our users needs. The recent thunderbird
issue was a communication problem more than anything else, and shows
that we need to make sure to work closely with upstream and be
advocates for our users there.
Kyle Martin - FESCo
I believe these things have to be addressed on a case-by-case basis. While I believe that the Mozilla trademark policy may harm us by delaying us from occasionally shipping patches, I believe it would harm the distribution worse to not have the name recognition and icons of the Mozilla project. Perhaps some passive aggressive push back could encourage the Mozilla Foundation to change their policy, but I do not believe stripping the icons and names as Debian has done with iceweasel is beneficial for our users either.
Matthias Clasen - FESCo
Mozilla's interest in ensuring quality and recognition is something I understand very well. In fact, we have similar rules in place for the Fedora brand, and taking a hard-line stance on this can easily make us look hypocritical.
It is in our best interest to work with Mozilla in finding the best compromise between their justified interest and the freedom that we are both interested in. And our firefox/thunderbird/xulrunner package maintainers are doing just that: working with Mozilla to get fixes tested and released as fast as possible.
The 'packaging rules' are just guidelines. Exceptions and domain-specific additions are best worked out by the packaging committee and FESo and the packagers.
Steven Parrish - FESCo
Granting exceptions can open a door you would rather keep closed. As
soon as you make an exception for one group you will have a more
difficult time in denying similar requests in the future. IMO we
should have only unencumbered versions of software in the Fedora
repos. Anything else should be in RPMFusion or similar repo.
John McDonough - BOARD
While I think we need to be flexible, perhaps more flexible than we
have in the past, it is important to recognize our values as well.
Sometimes, as in the Thunderbird situation, there are multiple values
to balance. That situation, then, really doesn't lend itself to
becoming a precedent, since each of the competing values isn't binary,
but rather shades of gray. We should value our cooperation with other
Open Source projects, but we don't want to sacrifice our own freedom
without careful consideration.
Larry Cafiero - BOARD
After reading the discussion on the list and not completely understanding the issue, I am not sure I can answer this question with any semblance of authority. But from what I can ascertain, it appears from the exchanges that this is a Mozilla issue moreso than a Fedora issue when it comes to fixing a bug in Thunderbird. I would defer to those who are more experienced in these matters.
Mairin Duffy - BOARD
While I was familiar with and read through the recent devel-list thread
on Thunderbird, I was unsure what packaging rule(s) the Mozilla products
are in exception to - I did not see that referenced in the thread. I
read through the Fedora Packaging Guidelines
(Packaging:Guidelines) and the only
guideline I found that I thought might be the guideline in question here
is, "Packages should be careful how they use trademarks in Summary or
Description." However, if you read the actual rules under that point, it
seems to reference trademarks that are not for specific packages in
Fedora, but points of reference (this application supports file formats
created by $TRADEMARKED_SOFTWARE) in package metadata.
Since I wasn't sure how to answer the question since I wasn't sure how exactly Mozilla projects are in exception to Fedora packaging rules, I talked to Chris Aillon who heads up the group of folks at Red Hat who maintain the Mozilla product packages. I asked him if he knew what rule this question was referencing. He said the exception is that Mozilla product packages are not open for commits by proven packagers (see Provenpackager_policy). As Chris explains in both the related FESCo ticket (https://fedorahosted.org/fesco/ticket/369) and in the devel-list thread (http://lists.fedoraproject.org/pipermail/devel/2010-April/135239.html), the reasons for this exception seem pretty sound, and not limited to the Mozilla products' trademark situation:
- Firefox and Thunderbird are highly-visible and used by a large body of Fedora users - packaging mistakes and poor decisions will affect a large body of users in a very visible way;
- Standards compliance is important for HTML clients like Firefox and Thunderbird, and unproven patches may break compliance which for Mozilla is rightfully a concern as standards compliance is a big part of their brand;
- As a good FLOSS community citizen, Fedora tries to stay as close as possible to our upstreams (see PackageMaintainers/WhyUpstream).
For me, the only lingering concern was whether or not packagers in the community who don't work for Red Hat could, given proper understanding of the policies that govern these packages, gain commit access. Chris assured me that was the case.
I think that having software with widely-recognized trademarks is a good thing for Fedora and we need to nurture our relationships with those upstreams. Just as Fedora has a right to protect its brand under trademark, so do other FLOSS software projects.
Rex Dieter - BOARD
There are guideline exceptions granted for many legitimate reasons, though most of them are technical ones. I personally don't consider the trademark issue raised here all that relevant to rules exceptions, as the packaging is still fully modifiable and re-distributable, with the caveat that branding be removed if using unapproved code or patches.
Stephen Smoogen - BOARD
I think that in many ways this discussion is more a distraction from
real issues that community members feel important. Some people tend to
like black and white answers to things; either a bit is on or off.
Either a value equals something or it does not. So when approaching
many social/human issues they try to approach it with the same
dogmatic natures. Either a rule is enforced universally or it is
completely useless. Heaven's know that when I was younger.. I felt the
same way. The problem though is that the real world is not so simple.
Humans aren't logical automatons, and their interactions are made the
more complex the more there are and the longer they happen.
In any case, we need to be respectful of Mozilla's trademark rules in the same way that we expect our (Fedora's) trademarks to be used. Second we need to be respectful of the developer/maintainers who are managing the package. If they say they have a roadmap to address many of the issues (bundled libraries, tree updates, etc) we should let them get their work done and later verify that work is progressing.
The counter point is that if someone wants to package up iceweasel etc.. they should be able to do so following rules and guidelines we have for new packages. Some time in the future its value can be evaluated like any other package for desktop inclusion. However, I do not believe the problems rise to the level of forcing it to be the default or trying to force the current thunderbird/firefox maintainers to be coerced into making it their work.
Tom Callaway - BOARD
This is a complicated issue. For example, we do not permit others to
modify Fedora and still use the Fedora trademarks, so it would seem
somewhat hypocritical of us to say that Mozilla isn't allowed to do the
same thing. However, when you look at what we've actually done with the
Fedora trademark guidelines, we've created acceptable alternatives for
people who do want to make that change, specifically, the ability to use
the term "Fedora Remix" for modified works.
I would love to see Mozilla to take a similar stance, and work with us to be more flexible about the use of the trademarks (or to provide recognizable alternatives (e.g. "Firefox Remix"). I do think that there is value in those trademarks, especially to users who are entirely unaware of anything beyond "Fedora comes with Firefox". I'm hopeful that we will be able to work out some sort of compromise with Mozilla.
What is your take on guidelines for packagers with respect to adding new features into supported releases? I expect there will be exceptions, but there should be some guidance for what is generally expected.
Bill Nottingham - FESCo
In general, I think the supported releases should be treated with more
stability than they currently are. New major releases of software aren't
really appropriate, and ABIs should be preserved. The further you get from
the core of the OS, the more this could be relaxed somewhat, and I expect
there are some components that would need exceptions in any case.
Bruno Wolff - FESCo
I would like to see something written that provides guidance to packagers
to what kinds of changes are expected in released versions of Fedora. I
don't think there is a one size fits all, but I think we need to more strongly
discourage soname bumps, regressions, and significant user visible changes
in how applications work. This should be more strongly enforced for critical
patch packages and productivity applications (email readers, browsers, editors
and the like). I think adding features can be OK, if there is testing and
the changes are very unlikely to cause confusion or other problems for people.
In the end the maintainer needs to be the one making the call. For packages
like Wesnoth there is real tension between have a later release to play
multiplayer online and being able to use your save files. I don't think
an overly rigid policy can cover all cases with firm rules.
I do think we need to give guidance to new packagers, so there needs to be some written guidance somewhere that covers what we think is best practice.
Justin Forbes - FESCo
We do Fedora releases often enough that there should not a priority to get
new features into supported releases. As a rule, the most important
priority for stable release updates is to make sure they are tested, and do
not contain any incompatibilities or regressions. I really have a hard
time setting a "no new features" rule, as each package is different, and
there should be some level of trust with our packagers. I think a more
appropriate guideline might be to ensure that updates are tested as much as
possible, and that feature updates should not be able to bypass the regular
updates-testing.
Kevin Fenzi - FESCo
I would advise maintainers to not add new features in supported
releases in general. There may need to be exceptions, for example cases
where upstream has moved to a new branch and a security fix is needed
and can't be backported. Fedora releases every 6 months. That should be
often enough to add a bunch of new features, allowing users to move to
them on their schedule.
Kyle Martin - FESCo
As a kernel developer, I prefer to err on the side of cautious and conservative updates, and the principle of least surprise for the end user. That said, the kernel is probably one of the worst cases for this. Mind you, they live for a very very long time in updates-testing before being pushed anywhere near updates. That said, aside from bugs, which will always occur, the kernel's feature set does not change much from release to release unlike much more visible packages like desktop environments, etc., so the same rules may not apply as directly. In general, I think it depends entirely on the maintenance policy of the upstream project, the competence of the packager/maintainer, and the expectations of the users. We, as a project, do not attach a technical competence requirement to packagers to be able to fix bugs in their own packages, so expecting them to be able to backport security fixes from possibly vastly divergent development branches may be a tall order. In summary, I would prefer conservative updates, but there are many factors that effect that, so in effect "it depends."
Matthias Clasen - FESCo
I am strongly convinced that we need to treat supported releases like a
finished product, not like something to keep tinkering with. We go
through quite a bit of effort to stabilize our operating system for the
release, and I think we owe it to our users (and the testers,
bug-fixers, release engineers, etc who invest this effort) to let them
enjoy this stability.
If you need great new stuff, the next release is only 6 months away. If you can't wait that long, jump onto the branch leading to the next release right after alpha. That's only 2 months away. And there is always rawhide, for the even more adventurous. Rawhide will hopefully get more day-to-day consumable when the autoqa efforts start to take effect.
Finally, I hope that we will soon see kopers as yet another mechanism to get cool new stuff to people on an opt-in basis, without having them trust their entire system to rawhide.
Steven Parrish - FESCo
I am in favor of developing guidelines that encourage stability in our
releases. Users, especially of n-1 releases expect stability and
usually are the ones who are most effected by updates that introduce
new features or change existing features. Serious bug fixes and
security issues should be back-ported to these releases but
functionality should not be changed. The addition of new features can
be an impetus for the user to upgrade to the current release. This
will result in more work for the package maintainers but I feel the
trade off is worth it.
John McDonough - BOARD
The problem with features is that one person's bug is another's
feature. In general, I see no problem with adding well tested
features to a supported release, but we need to weigh carefully the
impact on the whole community. Too often, users are blindsided by the
adverse impact of a new "feature".
Larry Cafiero - BOARD
Coming from the Ambassador side of things, I am not as well versed in the guidelines for packagers as I should be. Having said this, I would have to look into this further, but in addition I would think that the current guidelines used by the Fedora Packaging Committee would suffice.
Mairin Duffy - BOARD
To me this sounds more like a question for FESCo than the Board. I do
believe our users depend on stable releases of Fedora being stable, so
if a feature is aggressive or de-stabilizing, care must be taken in
considering it for inclusion in a supported release.
Rex Dieter - BOARD
My take is let common sense be the rule. Some basic tests like: would introducing new feature X: improve the overall experience significantly? introduce disruption (to users or other packagers)? how well tested/understood is it? Those best well suited to weigh these factors are the maintainers. It is, of course, within FESCo's purview to provide guidance and oversight.
Stephen Smoogen - BOARD
I have a rather old fashioned view on it, a release should be as solid
as possible and change as little as possible afterwords. I have worked
too many jobs where large numbers of machines are installed off of
initial software and never updated. Or if they are updated, people
want what they had at the end of the release to look, work, act like
it was at the beginning. Yes they may want problems fixed, but icons,
applications, and sounds should act the same as it was when they got
it. I have had to downgrade or add my own patches on too many systems
because a menu now had 4 new items or had moved the order of the
items.
That said, this is not going to work for every application or tool. Many Fedora applications are still in what people call development stages and are updating/changing quite quickly because something didn't work or the audience did not like how something worked. Those audiences are not wanting to wait 6 months for some new item, nor are they going to worry too much if menus change or completely not work for a day or two.
At best, I believe we should look at segregating packages into two sets: Stable and Preview. Items in Stable are meant to stay pretty much the same throughout a release except for bug fixes that do not mess with functionality. [A good example of this would be GCC. Having to completely change your tool set every 2 days would drive most developers to distraction as they would not know if the reasons something is not compiling is because of their own changes or GCC using Ferengi notation now as new middle layer.] Items in preview are meant to be changed out and not going to make any promises about levels of stability in look and feel.
Tom Callaway - BOARD
Again, this is not a simple issue. I maintain a lot of packages in
Fedora, and I have some packages like R, where the userbase expectation
is that the R package will get updated to the latest version for all
active releases. I've also got some other packages where I explicitly
don't update for new features, because the userbase expectation is that
they prefer stability over features.
So, to answer the question, I think that:
Packages in the critical path (the default packages installed from a
spin) should not get major feature changes during the lifecycle of a
release, unless it is unavoidable (and in that situation, the case is
reviewed by FESCo first).
Packages outside of the critical path should avoid doing major feature
changes during the lifecycle of a release, but the packager is permitted
to do so at their discretion.
Packagers who wish to maintain a "bleeding-edge" repo of packages for
active releases (with something like copers) should be able to do so,
because it allows users to make a conscious choice to move to that.
What are three things you intend to work on and complete during your time on FESCo -- in other words, personal goals for your term?
Bill Nottingham - FESCo
1. Changing the development culture to be more productive, if at all possible
2. Try to work towards consistent guidelines across packages where possible,
instead of 'every developer has their own guidelines' (with respect to
ABI stability, updates, and other procedures.)
3. Work to increase the uptake of community testing of Fedora,
to catch the bad bugs before they hit our users.
Bruno Wolff - FESCo
I'd like to see written guidance intended primarily for new packagers on
under what conditions updating to the latest new version is probably a
good idea and when it is probably a bad idea.
I plan to work on getting the Ogre libraries and some related packages updated to current upstream for F14 so that some of our 3d games work better. (I plan to do this whether I am on FESCO or not, but since it will take a significant amount of my time I wanted to mention it as one of my projects.)
I want to see some improvement to live images in order to support larger installs. In particular I want to get lzma compression enabled (is blocked on a change to the upstream kernel that might happen for 2.6.35) and support for some other file systems (in particular NTFS) in the iso to live usb tool. (I plan on working on this whether I am on FESCO or not.)
Justin Forbes - FESCo
Improve the focus on QA
Improve community involvement and feedback from the FESCo process
Improve focus on the community goals for Fedora.
Kevin Fenzi - FESCo
1. I would like to see the Fedora Engineering Services take off and
flourish. More tasks, more engineers, and more people moving forward to
fix things in Fedora.
2. See changes to the current updates system put in place, and start
discussing where we can take our updates system down the road (in a
year or two). I'd love to see the simple karma system replaced. I'd
love to see a framework for test plans and other QA on updates.
3. I'd like to see the Fedora Classroom take off and have a continuous
stream of classes going on.
Kyle Martin - FESCo
There are three things I would like to see from FESCo this year.
Foster an environment of technical leadership from FESCo. Not issuing edicts, but helping set the technical direction of the Fedora OS.
Push for a Fedora Technical Lead who is trusted by the developers and FESCo in the same way that the Fedora Project Leader rallies the community, this is related to #1, obviously.
Less redundant work for FESCo, there's no reason every provenpackager request must be voted on by FESCo. I confess at least to probably not being the most qualified person at Fedora packaging to be able to vote on them, whereas I think I have the experience to serve in other capacities.
Matthias Clasen - FESCo
I want to assist in finishing the important changes that are currently
underway:
- The autoqa efforts to improve the day-to-day usability of rawhide and
the quality of our updates.
- Improving our update experience.
On a more personal level, I want to ensure that the transition to GNOME3
goes smoothly, and that Fedora becomes the premier GNOME3 distribution.
Steven Parrish - FESCo
1. Stability / Critical path for all spins
2. Encourage innovation (ie incorporate new features) and keep Fedora
on the leading edge
3. Work on defining FESCO's role and so that SIGs can be given more autonomy
What are three things you intend to work on and complete during your time on the Board -- in other words, personal goals for your term?
John McDonough - BOARD
As I see it, the main opportunity areas are connected. It's all
about improving communication. We need to 1) be better at recruiting
and utilizing new contributors and, 2) reduce the acrimony that
sometimes pops up. Much of this has to do with making information more
accessible. I see a couple of key opportunities here:
The Wiki: We try to document everything on the wiki, but it borders on impossible to find anything. We need a wiki gardening "project" or team working closely with the Design Team, perhaps even a part of the Design Team. This group would understand each group's work processes, and arrange access to information in a way that makes sense in the context of those work processes.
A key work process that is important for every group, and different for every group, is the assimilation of new contributors. The first priority for this wiki team should be to understand how each group assimilates new contributors, and what information the new person needs. An organized, thoughtful flow should then be incorporated into the wiki so that the new contributor doesn't feel so overwhelmed when joining the project. Although existing contributors are usually more than willing to help, newer folks are often reluctant to "impose" on others, and are more comfortable discovering things for themselves. We want to make that discovery process as painless as possible.
Data: We can imagine that we are improving things, but without metrics we don't really know. We have a lot of metrics, perhaps not all that we need, and perhaps some are redundant, but in all cases, they are hard to find and hard to digest. We first need to make the data findable, another task for the previously mentioned wiki team. But then we also need to make the data understandable. We should instill a culture of clearly showing why a particular decision makes sense, based on hard metrics wherever possible. The data must be presented in a compelling, visual form, something we have rarely, if ever, done.
Acrimony: In addition to making data visible and encouraging a culture of data-based decision making, see the comments below.
Larry Cafiero - BOARD
A. Three goals:
1. Achieving and/or maintaining a healthy and responsible growth for Fedora – “healthy” and “responsible” are key words here, meaning keeping on task with Fedora's goals and principles while making sure the skill sets and (hopefully) personalities of both established Fedora community members and new community members mesh going forward. both internally as a community and externally as an operating system used by the general public;
2. Maintaining Fedora's standing in the Free/Open Source Software realm by cultivating and nurturing already established relationships in this area while exploring new, mutually beneficial relationships, should they arise;
3. Not getting killed in the entire process.
Mairin Duffy - Board
1 - I want to work together with the Fedora community in establishing a
vision for Fedora that we all want to strive towards. In an ideal world,
5 years from now, think about where you'd like Fedora to be. How do you
see Fedora being used? Who do you see using Fedora? While there are a
lot of differences between different subgroups within the community, I
do think we share very similar dreams for Fedora, but it's not something
I see us talking about a lot. We tend to get mired down in specific
issues and we don't have a visionary roadmap to guide our decisions
within those issues. I'd like us to build that vision together, making
it easily consumable and spreading it throughout the community. I think
the vision could be manifested in a lot of fun ways - comic strips,
videos, illustrations.
2 - I would like to see fedoraproject.org completely revamped, to provide a competitive user experience so we can improve the experience our current users have with Fedora as well as effectively attract more users. Our website is our primary communication interface with our users, and right now I strongly believe its design is not reflective of Fedora's quality nor is it inspirational for prospective users. I can say this knowing that the website has never been properly designed for that purpose - I worked on the design that is currently up on the site now and back when it was designed (I believe the timeframe was originally F7 or F8) the main goal was to make the site as lightweight and non-bandwidth intensive as possible to prevent putting a huge load on our and our mirror servers during release. We didn't want prospective users getting 404 errors! Now, our infrastructure is more sophisticated and we are lagging behind other operating systems in showing our face to the world. I've been part of a project with some of you to design a new fedoraproject.org (Website_redesign_2009) and already the spins.fedoraproject.org part of that project has been realized, but we need to finish. I'd like to see an amazing website for our operating system by F14. Do you think we can do it?
3 - I would like to provide an additional source of information on Fedora Board activities through my blog. If you have followed my blog (http://mairin.wordpress.com) on Planet Fedora, you've probably noticed that I work pretty hard to document conferences, design processes, and meetings in a way I hope is thoughtful and compelling, soliciting your feedback. I'd like to do this for the non-sensitive (the majority) Board activities I participate in as well and bring any feedback you provide back to the Board.
Rex Dieter - BOARD
It is my firm belief that an important goal of leading (especially in this context) is to facilitate bringing people and groups together, guiding the formation of common goals and, as much as possible, finding consensus.
Another personal goal is increasing my personal outreach: by blogging more, attending conferences, actively facilitating other contributors' efforts
Stephen Smoogen - BOARD
A) See about making voting mandatory in certain elections to remain in
good standing. I believe that voting is a responsibility and a
non-vote is not a 'protest' but a revocations of one's rights. I would
want to make it clear that joining Fedora has various responsibilities
as much as freedoms.
B) Better discovery and communication of what the Fedora 'brand' means. This has been brought up many times before, and gets a guttural rejection from various people. I think it has to do with the feeling that they may find that they don't belong any more, or some other issues. However, looking at other projects, I have seen that the ones that are best able to bring in new people are able to clearly communicate some definite ideas and then leave a large fuzzy area for the rest.
C) Seeing how to better grow Fedora and Linux into educational schools. We have had strong initiatives in the past to do this, and like any hard task requires a continual effort. I would like to be able to see how I can do this from a board level and help keep things moving so that everything from Elementary to Universities (the American K-20) has a growing Fedora presence.
Tom Callaway - BOARD
I want to set big goals, goals that span multiple releases. So, my three
things are:
1. Improve usability of Fedora for all users
2. Gently encourage users to move from consumer to contributor
3. Encourage Fedora to be an innovation leader, by encouraging and
adopting initiatives like GNOME 3 and systemd
Other than the general idea of better communication, name a specific improvement you think would help one or more Fedora teams work more efficiently, either individually or together.
John McDonough - BOARD
My answer to this almost fits the FESCo question about technical
improvements. We need an open-source GoTo Meeting or something
similar. GoTo Meeting may not be exactly the right model, but we need
a more graphical collaboration tool, and preferably one that provides
some sort of fairly comprehensive logging capability. There are a lot
of things that really go a lot better if they can be done in real
time. Gobby/Talk works quite well, but it would work better if it
were more visual, and recordings of Talk sessions, while useful,
require a lot of dedication to sit through. Something that would
simplify the display of prepared diagrams, as well as permitting on
the fly diagrams, while still maintaining the fluidity of Gobby could
be a big win.
The challenge here, I suspect, is more in imagining just what such an application would look like. Again, I suspect Mo and the crew would be the best resource here. If we could understand what such an app looks like, I have no doubt that we have the talent to make it so.
Larry Cafiero - BOARD
Better communication is probably key to teams working more efficiently. As for any specific improvement, I think it would boil down to improved communication, so I don't have a specific answer other than to monitor teams' interactions and point out how they could better communicate.
Mairin Duffy - BOARD
Our primary communication channels - IRC, mailing lists, email,
tickets/bugs, commits, and blogs for the most part - are primarily
text-based. All but IRC are non real-time communication methods. I think
that non real-time communication methods are important to us as a
project, because we are all dispersed across many different time zones
and it would be unfair to center our communications around time zones to
the exclusion of an entire body of contributors. Non real-time
communication methods also allow non-English speakers additional time to
clarify confusion over meanings - providing time to consult a translator
or dictionary. Oral communication can be a greater challenge to
non-English speakers compared to text-based communication.
Non real-time, text-based communication unfortunately decreases the probability of identifying and correcting misinterpretations and incorrect assumptions when they occur. For example, you may read a series of posts to a mailing list thread and find yourself quite deep into the thread when you finally realize you misunderstood a key point made in the first post. Travelling down this wrong road for an extended period of time in a communication can be frustrating and exhausting and lead to some bad feelings.
I have a few specific ideas on how we can improve communication within Fedora that I think address what I believe are causes of the communication breakdowns we experience (as noted above):
- Easy file sharing with notifications. Within the GNOME project, UX designers have struggled to communicate effectively with each other, share and critique designs, and generally keep up with one another. At the GNOME UX Hackfest in January, we discussed a FLOSS Dropbox-like system as a potential solution to this communication issue (see http://mairin.wordpress.com/2010/03/01/the-one-where-the-designers-ask-for-a-pony/). Hylke Bons, an GNOME UX designer who works for Intel, is working on a git-based solution. I think a tool like this would not just benefit designers, but would help many groups within Fedora in communicating more effectively. Imagine having a shared folder on your desktop that other Fedora contributors can view and post updates to, and receiving notifications when they are working on those files so you can jump in together, and having version-control on those files in case something goes wrong.
- Bringing mailing lists into the 2010's! It's been a long time since Mailman's interface has been improved. I have been discussing a small side-project idea to address this both on Fedora Planet and with Luke Macken from Fedora Infrastructure. You can read more about this project here: http://mairin.wordpress.com/2010/03/16/a-rich-web-interface-for-mailing-lists/
Rex Dieter - BOARD
I strongly support FESCo's recent request of SIGs and various groups to provide periodic (weekly or otherwise) reports of activity and progress. I believe this has the potential to greatly improve openness and transparency, which are important foundations to building trust.
Stephen Smoogen - BOARD
Enabling more face to face communication. We humans are very social
creatures with many built in audio-visual requirements in order to
trust each other. In learning to deal with autism, I have come to
realize how much miscommunication occurs when they are not available.
While video technology would improve some things, it is not a
cure-all. We need to make sure that people are meeting regularly at
events and conferences to hash over problems like trademarks, release
features, etc. Events like these need to be recorded as we also have
many people who worry about back room deals when people change their
minds after meeting someone else.
Tom Callaway - BOARD
I can't claim credit for it, but I do think that having more public IRC
Board meetings, where members of the Fedora teams come and present their
latest status help us to work much closer together, is a very good idea.
Name a new technical capability that you feel the Fedora distribution does not include now, but should have by the release of Fedora 15.
Bill Nottingham - FESCo
Well, I think this overstates the ability of FESCo to specifically
direct development. If you're just asking what I think would be nice to
have, easy replication of personal data and integration with free online
services, such that if your laptop happens to die in a fire, it's easy
for you to get back in business quickly with your data and your apps.
We're also in an area where there's an excessive amount of information coming at the user to process, oftentimes disrupting their focus. Organization of incoming information (whether it be e-mail, web, blog, microblog, IM, or whatever) so that it presents the user with what they need, while still letting them concentrate on getting their work done, would be great.
Free and open audio/video codecs without software patents would be nice too, but I'm not holding my breath.
Bruno Wolff - FESCo
A project wide calendar, that provides ICAL data and that can be used for
tracking meetings, classroom sessions, special events and project tasks.
Justin Forbes - FESCo
An implementation of spice.
Kevin Fenzi - FESCo
It's hard to predict the future. ;) I'm constantly amazed at some of
the features Fedora folks come up with. To pick a random thing that I
would love to see: Fast, stable, 3d on all the major video chipsets out
of the box (we are getting there!).
Kyle Martin - FESCo
It would be supremely excellent if KMS was working to a point where we had proper oops-over-X display working.
Matthias Clasen - FESCo
I think Fedora has plenty of awesome raw technical capabilities under
the hood. Adding one more is not going to make a day-and-night
difference.
What I want to see improve is the integration of these technical capabilities to the point where they make a real difference for day-to-day desktop use.
One example I have in mind here is firewall configuration. Our current firewall handling breaks a lot of the sharing capabilities of our desktop in a default install: personal file sharing, music sharing, other avahi-based services, etc. And to 'fix' your installation with the tool we ship (which you really shouldn't have to do in the first place), you have to understand a lot of cryptic terminology like protocols, ports, and more.
Another example is virtualization. We have truly impressive tools here, like virt-manager, but there are many small 'fit and finish' things that would make a big difference here, like being able to download a test iso and just click on it to launch it in a VM, or having working Copy-Paste between VM instances.
If you insist on naming a technical capability, I will say that being able to run gnome-shell in a VM would be pretty awesome. Achieving that by F15 may be challenging, though...
Steven Parrish - FESCo
I have a few things I would like to see in Fedora. The long talked about kopers see http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos. Also
improved metrics.
How are you going to represent the Fedora community (the voters) on FESCo: They vote once, you decide for the period of your appointment - or you ask for input and base your decisions on that?
Bill Nottingham - FESCo
I take input as it occurs, and filter it through my own personal judgment.
I have enough of a record in Fedora that I would assume that the voters who
vote for me are not going to be too shocked by any position I would take.
Bruno Wolff - FESCo
I am not planning on taking straw polls of the whole community to make my
decisions. This effectively turns respentative democracy into direct
democracy, which I don't think is a good way to run Fedora.
That isn't to say I might modify my decisions based arguments supplied by people outside of FESCO. However I am not going to count the number of people supplying the argument to decide whether or not I should agree with it.
I plan on making decisions that I think are correct and in the best interests of the Fedora Project.
Justin Forbes - FESCo
I hope that I am elected for my ability to think in the best interests of
Fedora. As such, it might be a bit silly to ask for input for every
decision. At the same time, the responsibility of FESCo is to the
community, not to our own agendas. Input from the community via
email/mailing lists/IRC will all play a role in the decision making
process. In the end, we have to balance what individuals want with what is
best for Fedora.
Kevin Fenzi - FESCo
Both. I would use my judgment and experience, but also be open for
input from folks as time goes on. I've been known to change my mind
based on well reasoned information. I'm always happy to listen.
Kyle Martin - FESCo
I believe that in electing me, the developers who vote have put their trust in me to base my decisions on my experience. That said, my opinion is rarely ever made up, and I would welcome anyone to contact me publicly or privately with issues they may want to see addressed.
Matthias Clasen - FESCo
I am certainly going to discuss topics with the interested community
in #fedora-devel, #fedora-desktop and on the mailing lists and form my
opinion based on this. But I am not going to be the representative of
the desktop SIG or any other special-interest group. I hope that people
will vote for me based on their perception of my ability to think and
reason, not because they hope that I will be their vote-bot in FESCo.
Steven Parrish - FESCo
Things move fast in FedoraLand. There is not time to poll the
community about every issue. People are elected because the community
feels they represent their views. They have to trust the people they
vote in to make informed decisions. I will look at each issue and
gauge the impacts on the community as a whole and make what I feel to
be the right decision.
How are you going to represent the Fedora community (the voters) on the Board. They vote once, you decide for the period of your appointment - or you ask for input and base your decisions on that?
John McDonough - BOARD
A couple of key things I have learned over the years; 1) Follow the
data and, 2) more heads are better than fewer. While there will likely
be some cases when I would specifically ask for input, in most cases I
will follow the discussion. Often threads on some issue or another
bring up important points that don't really bubble to the surface.
Understanding all corners of an issue is important, far more important
than hearing who is yelling the loudest. But when there is data, data
wins, and as an old Six Sigma guy, I have a lot of tools in my belt
for pulling data out from where there appears to be none.
Larry Cafiero - BOARD
As I said in my statement of candidacy, leadership comes from the ground up, not from the top down. While board members are the ones that make the final decisions, it is in their interest to seek out viewpoints and information from the community as a whole to make the most informed decision. So personally speaking, I'd hope that other board members would join me in seeking the input of the community when making decisions.
Mairin Duffy - BOARD
I don't believe I know all the answers when I'm designing user
interfaces and artwork for Fedora, and I've asked many of you to look
over my design work and the work of our design team to provide your
feedback so we can adjust our designs, incorporating some of your ideas.
In the same manner, I don't think I'm going to know all the answers as a
Board member, and I will be absolutely be asking for your input when
making decisions. I hope you don't mind. :)
Rex Dieter - BOARD
My primary motivation behind any decision I make as a board member will be the health and well-being of the project as a whole. Informed decisions cannot be made in a vacuum, so mine will obviously be based both on my own feelings and experiences as well as those of our community as well.
Stephen Smoogen - BOARD
I will ask for input as much as possible, but at a certain point my
decisions will be what I feel I can 'live' with the most. It doesn't
mean I will be always right. I try to live by the rule that most
people's average 'batting averages' is 0.200. That means 80% of the
time we are going to make a mistake, and we have to learn how to best
correct from them.
Tom Callaway - BOARD
Well, this is a representative system. I have to feel that the people
who voted me have faith in the decisions that I have made and the
policies I have proposed. When an issue is before me that I am not
familiar with, I always try to do my best to research the issue and talk
to people who are knowledgeable on the topic.
I feel that I have a solid track record of listening to the community and representing it well. An example of this is around the Fedora CLA, I've heard the concerns from community members about it, and I've worked with Red Hat Legal to completely change it to be more clear and more useful for Fedora's needs.
And hey, if people feel like I'm not representing them well, I'd like to know about it. My inbox is always open, and I'm available all over the interwebs (IRC/twitter/identi.ca/facebook/IM) for anyone to bring up a concern.
Bill Nottingham - FESCo
To see if I'll ever learn? So far I haven't.
Bruno Wolff - FESCo
I heard that FESCO members get time on the Orbital Laser.
Justin Forbes - FESCo
I'm just in it for the money... Oh, wait, no money with this gig??? ;)
Kevin Fenzi - FESCo
Complete world domination for Xfce of course!
Kyle Martin - FESCo
Taking over the world, obviously. ;-)
Matthias Clasen - FESCo
I can't tell you :-).
Steven Parrish - FESCo
Fantastic Cosmic Powers
John McDonough - BOARD
To be honest, it hadn't really occurred to me until late in the cycle
when some of my friends on the Docs Project suggested it. I don't
really have the fire for coding anymore to contribute as a developer
in any significant way, even though my development background is
extensive, my marketing skills are underwater, but not nearly as weak
as my artistic skills, and this seemed to be a way I could expand my
contribution beyond the Docs Project.
For whatever reason, I always seem to end up in leadership positions. I must have some capability there, why not lend that capacity to Fedora?
Larry Cafiero - BOARD
<joke>World domination.</joke> Actually, I got into the race after a discussion in #fedora-ambassadors on the day the nominations close, where the consensus seemed to be that there was too much apathy in this election. Currently I serve as the Regional Ambassador for the US West Coast states and as a mentor to new Ambassadors, and I decided to run because wanted to bring this experience to the Fedora Board. Nevertheless, all the candidates for the Fedora Board in this election are outstanding people that bring great Fedora credentials with them, and the Fedora Project cannot lose with whomever is elected to the board this time around.
Mairin Duffy - BOARD
I have a couple of hidden agendas in running for the Board:
- I tried to provide guidance to the Board when asked in the Target Audience definition project, but I did not have the time to do it right. I'm a little disappointed in the current outcome of that project, and I think I can more effectively help with the project as a Board member. I think setting a vision we can all agree on for Fedora is the single most important thing the Board can do to help us succeed as a project.
- I was really floored when I realized the Fedora Board has not yet had a female member. Since I first joined the project, I have happily watched the number of prominent female contributors grow and I think we need our formal leadership to reflect that growth.
Rex Dieter - BOARD
My hidden agenda is to work towards making hidden agendas impossible or obsolete.
Stephen Smoogen - BOARD
My hidden agenda is pretty much that I felt it was my responsibility
to run at least once. I really wish I had something more witty or
humorous to say here, but its pretty much there.
Tom Callaway - BOARD
Three words: Ninjas. Raptors. Silly Putty.
There appears to be a disturbing increase in the amount of flames/annoyance/anger/frustration within the the Fedora project of late.
Bill Nottingham - FESCo
I'm not sure it's actually 'of late'. In fact, this was the 'one
thing I'd like to change' that I mentioned in the *last* election
questionnaire I filled out. (http://fedoraproject.org/wiki/Elections/Questionnaire)
I'd attribute it to the same things then; a lack of clear direction and each
user thinking their own personal goals are what's most important. This
then leads to a lot of politicizing, and then nothing ever gets done.
As for addressing it, I guess I didn't have a lot of success. The best way is to probably define some overriding goals such that there's a rational basis for reaching compromise or consensus in discussion.
Bruno Wolff - FESCo
I think some of the recent flames have to do with trying to as a project
state some of our policies while our members have held conflicting views
of what these policies were. Without them being stated in the open our
members could often hold conflicting views of what they were without noticing
the conflict. Now that there is a discussion has brought the conflict out
in the open, people are arguing that their view is the correct one.
I think part of the issue is that some Fedora members are passionate about the project. While this can be a good thing, it can also make conflict resolution difficult.
On a personal level, I am going to try to be more selective in adding to those long threads, unless I feel I have some new and relatively positive to add.
I think people need to take the "Be excellent to each other" motto to heart. While people may have serious disagreements about the future of Fedora, I don't think anyone in the discussions is intentionally trying to hurt Fedora, but I think sometimes the responses treat people like they are.
I don't think the "Hall Monitoring" has worked.
I think the problem is going to take people individually showing restaint, respecting other people even if you disagree with them and trying to stress the common ground. In some of these heated discussions I think people have really been in a lot more agreement of what we want in the end, then you might guess based on the tone of the arguments.
People should very much avoid sarcastic remarks. I think those are very poisonous. And I especially expect people in leadership positions to set good examples.
One thing I have been working on (at the behest of Kevin Fenzi) is Fedora Community Gaming. The idea is if people play together they will have more of a personal connection which will help smooth dealing with conflicts and make people more comfortable asking for help outside of their normal teams. So far it hasn't been a success, but it hasn't been a total failure either. If attendance doesn't pick up in a month, I'll probably drop it as not being worth the time. But other people are free to sponsor sessions as well.
Justin Forbes - FESCo
We are a large community, and as such, there is always a measurable amount
of frustration/flaming. It gets more visible or less visible over time,
usually more visible when there are process or policy changes. As a member
of FESCo, it would be my job to look past the flames and frustration, and
keep an eye on the technical issues at hand. If those can address some of
the flames, all the better.
Kevin Fenzi - FESCo
I think it's a natural case of a large project picking up some vocal
folks/detractors and it seems to come and go in cycles. I think if we
all be excellent to each other and show how to behave, the folks who
are not doing that will be be ignored or bypassed. In the case of
someone causing technical problems I think FESCo could ask them to
change approach, or even leave the project, but for social problems it
would be more of a Board issue.
Kyle Martin - FESCo
I attribute this to a lack of a coherent direction for the project. Half of the packagers seem to be content making something for their own consumption, whereas the other half believe our direction should be producing a coherent and consistent operating system, as opposed to a collection of packages we collect and ship every six months. I'm not sure what the best way of addressing this, as it reflects a fairly deep schism in the community. It seems no matter what is done, half (obviously it isn't a fifty/fifty split, but it serves the purpose of illustration) the community will be unhappy with either direction, so perhaps more tolerance of the opinions of others with some offline reminders to people when they cross the line would avoid the confrontational and long winded email threads which have been occurring.
Matthias Clasen - FESCo
The increasing level of frustration is coming from a lack of shared
vision or direction. Spins seemed to address this at first glance, by
giving the various groups a chance to move in their own direction for a
little bit.
But from a longer-term perspective, I think treating spins as equal offerings is detrimental and makes the problem worse, not better. We are now offering a bunch of different user experiences, all under the name 'Fedora'. That not only causes confusion to the user, it also forces us into continuous fights over changes in anything that touches more than an individual package, without any resolution.
Addressing this problem is not easy, but it is essential to the survival of Fedora as a relevant entity. If we just keep pushing in different directions, and fighting over it at any turn, there may still be Fedora in a few years, but it will not matter much anymore.
I don't have any grand solution to offer, unfortunately. If there was such a thing, the smart people that are currently serving on the board and FESCo would have probably found it already, anyway. But I can name some (IMO) important ingredients for a solution:
- Build one thing, with a clear focus (it doesn't have to be the only thing we build, but it needs to be the centerpiece around which the project can gather)
- Write rules down if things are unclear or disputed, after a _limited_ discussion (see the 'security policy' that we established after F12).
- Don't allow combative or poisonous people to drown out productive discussion and prevent decisions.
- A clear vision and shared goals avoid costly disputes and give us an opportunity to attract new users, contributors, and upstream OS developers.
Steven Parrish - FESCo
As the project and community grows you are going to have friction
between long time contributors who are used to a certain methodology
and new methods and agendas. Projects change direction, and as a
result you can end up alienating people. You cannot please everybody
and projects that don't grow and change will wither and die. As
Fedora grows new guidelines and processes must be developed and
implemented to help manage and sustain the project to the benefit of
the entire community.
Some people may not be comfortable with the changes and may leave. To them I say thank you for all your contributions, your talents will be missed.
John McDonough - BOARD
In terms of reducing acrimony, again, communications and having the
data to support a decision presented in a compelling way will
certainly go a long way. There is also a lot to be said for setting a
proper example. But we also need to establish a process where the
more "passionate" contributors can be assisted in seeing that
acrimonious comments only hurt their case. The old adage about
catching more flies with honey than with vinegar certainly comes to
mind. We should develop a process where folks who are taking a
counterproductive approach can be quietly mentored and assisted with
their interpersonal skills. There are people who are good at that
sort of thing, perhaps we need to recruit them.
Back in March I went to a GNOME summit, where I got some close exposure to some of the other projects close up. The difference between some of the other distros and Fedora is striking. We have something very special here, and we need to do all we can to protect and leverage what we have.
Larry Cafiero - BOARD
I attribute the fact that there are flames/annoyance/anger/frustration within the Fedora Project to human nature, which is baggage we all bring to the community. Recently, some of the conflicts that I've seen arose when the enthusiasm of new people collided with the standard procedures already in place at the Fedora Project. In many instances, it's an accomplishment to focus unbridled enthusiasm within the context of established procedures without conflict. While this is just one example, the fact that we should do our best to be civil in our disagreements, when they arise, goes without saying. Speaking personally, there are times when I have to make a conscious effort to “be excellent to others” during the heat of a debate or disagreement, and I hope others do the same. In addressing this, I would have to say that the best thing to do would be to focus on the conflict at hand and try to defuse it.
Mairin Duffy - BOARD
I attribute this issue to both our growth as a project, and the
text-based nature of our primary communication channels. I already
mentioned some ideas on improving communication in a separate question
above, so in this answer I will focus on the growth issue and how I
believe we can address it.
As a project, over the past few years we've grown a lot in terms of our number of contributors. (see Statistics#Contributors) We have over 25,000 Fedora accounts right now, as compared to less than 5,000 shortly after we first introduced the click-through CLA system in 2008. However, there is a limit to how many other people any single person can coordinate with informally and organically, and I do think a lot of the vision that drives Fedora is not formally-stated or widely-socialized within our rapidly-growing contributor base. In the absence of a central vision to follow in making decisions, contributors have formed disparate islands with goals that at times conflict with the goals of other 'islands' within the project. I don't think this is the contributors' fault. It's the way I believe any sensible person trying to accomplish a goal would handle the situation - it doesn't solve the root problem, however. We need a central vision to drive our work as contributors so we're working together, not at odds.
I believe that my background as a user experience designer - a discipline we have not yet had on our Board - will be an asset in rectifying this situation. As many designers out there will tell you - including the designers on Fedora's design team - it can be very difficult to move a design forward without working to gain the buy-in of the client, users, and developers involved. (see http://www.slideshare.net/tigerfork/achieving-stakeholder-buyin-for-user-research for an example of how designers typically approach the buy-in process.) I think that if we can together paint our vision for what and where we want Fedora to be, and successfully sell that vision across our widely-expanding community, then our work in building Fedora will stand a much greater chance of successfully reaching our users and spreading FLOSS - goals I think we all share.
Rex Dieter - BOARD
Disagreement on some things is inevitable, but when that grows into something bigger like anger and frustration, experience tells me primary causes include feelings of helplessness and a perception of not being heard. Potential solutions include working toward making clearer to our community that they are both empowered to make a difference and that their voices are, in fact, being heard.
Stephen Smoogen - BOARD
There are many reasons for it. Some of it is that Fedora is not the
distribution some people thought it was, and as they are coming to
grips with that anger and annoyance come from it. Some of that
disconnect is due to Fedora ageing from an innovator market to a more
mainstream level. At times the two have highly divergent needs, wants,
and languages. These changes always cause large disconnects, anger,
and confusion. In the end, it comes down how each individual wants to
deal with change which leads me to a Zen joke a boss told me long
ago.. I didn't get it for a long time, but when I did it was like
being enlightened:
Q: How many Psychiatrists does it take to change a light bulb? A: None; the bulb will change itself when it is ready.
There comes a time that every contributor has to realize that whatever anger they have is usually not really at what they write their emails at. For me in the past, it was usually a fear of change, of not knowing what the answer was, of not really understanding what others said. When the realization comes, they can figure out what they need to do next. Until then, one needs to listen as best they can and not get caught up in the emotional storm.
Tom Callaway - BOARD
I think much of this is because for a long time, Fedora has tried to be
all things to all people. Some of these people seem to think that
because Fedora is something to them, that it must always be that way for
everyone. I really do want to encourage people to feel like they can be
involved in shaping Fedora, but I also think that it can't possibly be
for every possible user or contributor. We can be flexible, but there
comes a point where we have to tell people that we're not just going to
do everything that everyone wants.
I'm not sure how you can really address this, besides asking people to be constructive, respectful, and polite when they disagree. I would hope that people are smart enough to realize that some ideas may not happen in Fedora the way they want them to, and either accept it, or look to another community where those ideas are a better fit (or even start their own community).