This is probably a bit late to the discussion, but wanted to get my thoughts down before I started chiming in on everyone else's... John Poelstra (poelstra@xxxxxxxxxx) said: > (a) Define a target audience for the Fedora distribution (or maybe > narrow the definition to "default spin")--without a clear target > audience for our product there is a lack of clarity around when we > are "done." It also makes it difficult to make decisions about > release quality and release composition. So... we have multiple pieces here. Fedora, the entire collection of packages. (This could be considered the Distribution). These can have one target audience. Fedora, a spin, or all the spins we provide. (This also could be considered the Distribution). These can have different target audiences, which may be different from the audience of the collection of packages as a whole. For example, the Games spin and the Electronics Lab spin have different audiences, and that should not be a problem. My feeling is that, if we were to use some sort of mission statement to describe it, Fedora's essence should be 'innovation made usable'. We want to present the newest innovations to users, but not so new that they don't work. And we want to be focused on making it just work, so they don't have to run 500 arcane commands, cut and paste config snippets from the web, or jump through other hoops just to use that innovation. Nor do we want to be pushing new innovation to them so fast that they can't keep up with it, or find that their way of doing things changes from week to week during a release. We also want to grow the base of users, as that's where our contributors come from, whether they be coders, documentors, artists, support staff on the forums, or whatever. Applying this to 'the Distribution'? I think we want to do two things: 1) put our best foot foward 2) innovate around the edges What does that mean? We should have a single default spin/release/whatever that puts our best foot forward for a specific use case, allowing us to attract more people to Fedora, some portion of which will then join the project as contributors. In order to be able to sanely grow the community around it, that default should be somewhat fixed - what the default is shouldn't be changing from release to release. As for 'target user'... the stock answer is the computer-literate user who wants a coherent, easy-to-use system that doesn't get in their way. We don't necessarily want to target all the way down to the user who's never used a computer before, but I think attempting to target only those who have Linux experience, or are already tinkerers, is too limiting. I feel this default should be something like the desktop spin; a clean interface targeted at a wide variety of users that can be easily extended for a large number of use cases. For example, a user can start with the desktop, and easily add a package or three to address the 'graphics designer' use case. Or add a few packages to address the 'developer' use case. It doesn't necesarily scale down to the server use case, but I think that's one case where we don't need the extra marketing; those in the server business are more famailiar with the Fedora Family Of Distributions, and don't necessarily need to be targeted in that way. But we also want to allow innovation around the edges - if this desktop doesn't hit the use case that someone wants to address, or someone wants to extend it into something more specific, we want to allow that. That's why we allow the wide variety of packages into Fedora, and allow for things like the Spins process and the Remix idea to target other use cases that we may not target in the default Fedora spin/distribution/whatchamacallit. That being said, when the objectives come into conflict between these usage cases, we should go back to the default spin/focus as the tiebreaker. You'll note this description doesn't really harp on project directives such as 'the Fedora Project consistently seeks to create, improve, and spread free/libre code and content.' That's somewhat intentional - while I don't want to *change* that focus, and that certainly should drive technical decisions where necessary, I don't think that's necessarily the best point to drive the target user around. To go back to the old free beer/free speech analogy - you bring the users in with free beer, and *then* you get them with the free speech. If we do our job right in creating the user experience for our users, the fact that it's all open source may not even be noticeable to them if they're not looking for it. > (b) Set some broad goals for where we want the Fedora Distribution > to look like a few release from now--say when Fedora 15 is released. > What should those be? - I'd like the produced images to be: - the default Fedora distribution as described above (could be a LiveCD spin) - the netinst/rescue iso - the spins Without a specific target audience, the current Fedora tree should go. - I'd like there to be a standard set of distribution tests so that when we compose a new livecd/spin/tree, we can, in an automated fashion, get a large variety of results quickly as to how well it works - I'd like 'israwidebroken.com' to resoundingly respond 'no' 95% of the time. > (c) Set some broad goals for where we want the Fedora Fedora Project > to look like a few release from now--say when Fedora 15 is released. > What should those be? - Metrics wise, an increase in contributors (hopefully across the board) - Development-wise, more actual development discussion on the devel list; patches, code review, feature proposals/discussion, etc. - An increase in task-focused spins. Right now, the focus of many of our spins appears to be i-want-a-desktop-too-but-not-that-desktop, which doesn't necessarily expand the use cases that people can hit with Fedora as much. > (d) Set a goal of five things we believe should be improved or fixed > by the release of Fedora 13 that will make the Fedora Distribution a > better product or the Fedora Project a stronger community. What > should those things be? These are more towards 'better product'. - QA QA QA. AutoQA doing automated tests, AutoQA mailing those test results to developers for review, AutoQA using those tests to block packages where necessary, AutoQA using those tests to promote packages where necessary. A database of past test results so we know what broke, when. - Defined policy around updating and maintaining released distributions. Not being able to concisely explain what sort of updates you get is a problem. - Set up a mechanism where large changes can be built in koji, set up as a repo, and tested sanely before being merged, ideally as a self-serve mechanism. That's not five, but if we get that far, we can come up with more. Bill _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
