User:Pfrields/FAB roundup

Agreed

• The Board owns issues concerning defining project-wide vision.
• The Board will resolve the following issues by the end of FUDCon in December 2009:
  • Target audience
  • Vision for Fedora Project by mid-2011 (F15)
  • Vision for Fedora 15
  • Short-term things to tackle for Fedora 13
• The Board wants the Fedora Project to be a hospitable environment for people who want to pursue goals outside this vision

Target audience

Member	Statement
mmcgrath	Experienced users and people that wish to aid in leading our industry through contribution, experimentation and science. (inventors, tinkerers, hackers)
pfrields	In terms of characteristics or approach, this person: ...is switching from $OTHER_OS to free software after hearing or reading about it, or seeing it first hand. ...expects things to "just work" as much as possible, and can sometimes be impatient as a result. ...doesn't want to go back to $OTHER_OS, and is therefore willing to fiddle occasionally -- on the order of 10-15 minutes or less per month -- to avoid it. ...accepts that software freedom has certain limitations, but wants to minimize (and if possible eliminate) any difference in capabilities vs. $OTHER_OS. ...won't pay for software. ...will contribute in the form of a bug report or helping others, if it's easy to do so with a few mouse clicks, but won't fill out long Web forms or do more than a sentence or so of typing. ...is interested in sustainable practices in general, but is not necessarily fanatic -- recycles packaging and goods, thinks "buying local" is worthwhile, volunteers at something a few times a year. In terms of skills and knowledge, this person: ...knows, or is capable of finding out, how to boot a system from an alternate device such as CD or USB. ...is able to open applications and make selections as directed in documentation or by a support agent (be it human or not). ...may not understand how free software is built, or how a free software project run (but is capable of learning). Clearly this person is not a developer, but including this person in our target audience does not disadvantage developers as end-users of the distribution. Focusing on this person's needs might mean that we the Fedora community might have to come up with better strategies for delivering software, or re-examine our release processes, or develop some new ways of creating the distribution/tree so that we can allow developers to maintain a high pace where appropriate, yet not have that boomerang on all users.
jwboyer	Someone that is moving from $OTHER_{OS,DISTRO} and is looking for something a bit more exciting and a bit less restrictive. They likely don't have programming skills, nor necessarily want to become developers. They generally want things to work out of the box, but they don't mind seeking help or helping developers debug a problem. They have a general knowledge of computers, have installed software in some manner before, are comfortable with basic computer terms like RAM, CPU, gigabyte, etc.
notting	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.

Vision for Distribution

Member	Statement
mmcgrath	An easy automated way to provide tests and the answers to those tests. IE: QA, targeted metric for some given configuration. More ISVs and start-ups have packages in the distribution. More Architectures. "Does Fedora run on $TOASTER?" Yes. A better reputation as a place to bring new ideas to be tested and presented as well as a better acceptance that failure of a new idea is not a bad thing. By F15 I'd like to see a killer virtualization management system in Fedora. What we have now is a lot of disparate tools. All of which are getting better, none of which are on the level with the likes of vmware.
pfrields	Educating user through distribution Better upgrade experience and update discipline for stable releases Better Rawhide model that allows for rapid development but more consistent testing/installation
jwboyer	Evolution. Continuing to showcase the latest stable FOSS and trying to provide a great experience out of the box. Consistent methodolgy in place for how we treat released versions of the distro in terms of updates, bug fixing, etc. Consistency across the distro is going to help users gauge what to expect. Pick a spin and focus primary development on that. To a large degree, we have started down this path already with the webpage redesigns, the reaffirmation that the desktop spin is our default, etc. This is not to say that there can't be other spins, or that we don't want Fedora to allow people to produce derivations. However I do feel that treating them all as equals and using terms like 'first among equals' is a disservice to the distro overall. A tiered approach provides clarity.
notting	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. 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 'israwidebroken.com' to resoundingly respond 'no' 95% of the time.

Vision for Project

Member	Statement
mmcgrath	Fedora is a laboratory where all the cool stuff happens. Stronger ties to educational institutions for the purposes of using Fedora in education (like POSSE) and also a place where academics can come to communicate, present works, do demonstrations, etc. A place where businesses and employees can come to work and collaborate towards common goals. Many businesses have started using FOSS, Fedora should lead them in how to take a step further and become a FOSS business. Also putting together better documentation on how and why employees are better employees when they work with FOSS projects.
pfrields	Build a more robust presence and community in Africa, China, and Japan. Complete package maintenance interface in one site/tool (i.e. less or no shuttling between SCM, Koji, and Bodhi). Using the Fedora Community Portal to connect new FAS members immediately with short-term tasks, and live mentors through a Web-based communication interface. Devote several FADs and FUDCon hackfests to coding the pieces needed as part of a planned project.
jwboyer	Development community participating in our processes as a whole. More education efforts for users (extending the Fedora Classroom ideas, writing content on how to do things, etc.) Less aversion to looking at other distros and reusing/contributing to things they have started that are beneficial to Fedora.
notting	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.

F13 Fix Points

Member	Statement
mmcgrath	A. I list this first because not only does it obviously need to get better but it seems obvious it will get better. The QA team has lots of neat things coming down the pipe. Better communication around how rawhide works. Both in terms of best practices in making changes to it and in communicating when updates are safe. (probably relates to 1, but can't entirely rely on that) Related to 2) I'd like to see a way for our rawhide developers to have their own rawhide branches. Similar to how there are different kernel trees. This isn't so they can have their own distro. But so they can more easily put massive changes in place to be tested for some small period of time before it is merged with "Jesse's tree" :) Better messaging systems for contributors and end users. Just in general a better experience in letting our users know what's going on in Fedora (news), what features are coming down the pipe (feature update vs just a normal update), etc. Additional ways for people to contribute to via the Fedora Project that are not the distribution itself.
pfrields	A coordinated effort between Alpha and Beta (or even post-Beta) to file and fix more bugs as a community effort, perhaps in the form of a focused week of effort across the Fedora community. Community Architecture support for bug parties, say $50-75/group to pay for hacker snacks. A central 'www.fedoracommunity.org' website that functions as a directory of other *.fedoracommunity.org domains -- the ones run by our community members that are separate and distinct from the fedoraproject.org domain. Improve the wiki documentation for schedule, freezes, critical path, and related info to make it dead simple for any developer (or heck, anyone) to figure out what is permissible at any point in the cycle. This should help eliminate guesswork, late code drops, and misunderstandings that can negatively affect the community. Not only that, but it means that we can more effectively create more robust QA and rel-eng communities because there's a lower barrier to learning what sometimes is institutional knowledge.
jwboyer	QA. Fortunately, we have made good progress on the rawhide front already. I'd like to see (and help with) more progress on QA of released versions and updates. A higher bar for Features. We have a hugenormous list of Features and it's starting to get a bit fuzzy as to what that means and how a new user could possibly even experience some of those. An actual secondary architecture release. We've had 'almost' releases since F8. I don't care which arch it is, but if we don't have a secondary arch that actually does a release I think it's time that we as a project just move on and stop worrying about it. (Or maybe we're already at that point and I'm the only one worrying) A clear process around the creation of the distribution. I think rel-eng is making strides towards this already, and trying to improve the experience for contributors with no frozen rawhide and auto-qa. I'd like to see us support that and invest in it because it will have a wide benefit. Easy one: auto-sign builds. Represent signed packages exactly as they are today: Fedora built this. That's it. Signing doesn't imply it's been tested or QA'd or that it is somehow a known quantity. It simply means the package as built by Fedora.
notting	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.
caillon	Define a list of core/critical-path functionality that packagers are required to ensure they do not break. Define a plan of action for what happens if such functionality becomes broken. See example[1]. Bonus points: come up with an easy to follow "smoketest" for how to determine whether something on the list is broken. Define update criteria for our release streams: what types of updates we expect, and what types of updates we do not want in each stream. Define a plan of action for what happens if an update fails to comply. See example[2]. Set up something similar to Mozilla's "Sheriffs"[3]. The Sheriff will be a rotating role and shall be responsible for coordination and enforcing of the previous two rules. If an issue arises, the sheriff will attempt to contact the packager responsible, and attempt to get them to fix or revert the issue. If this isn't possible within 15 minutes, the sheriff will find a provenpackager to do so. Improve our test suites. Provide $coolstuff incentive for people who contribute (the most?) valid test cases. Start an initiative to automate as much of the above as possible. Possibly as GSoC projects. Particularly, I'd like to see a tinderbox which creates VMs from a buildroot+ks file, runs automated tests for the critical path, and outputs the PASS/FAIL results. I'd also like to have a post-commit hook which reminds people to not break stuff and to be available to the sheriff on IRC.