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.
poelstra	moderately experienced computer users who wants to use Linux as a desktop (email, web surfing, office suite, software development) or to run simple web services they should not have to go to the command line to fix problems that come up due to bad package updates or other unintended regressions comfortable installing a new operating system themselves to a stand-alone machine (no dual boot or other craziness--wipe the whole drive and continue) someone interested in going deeper and learning more about how the operating system works

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.
poelstra	Our release processes are running smoothly and more people understand how they work--no last minute "I didn't realize Feature Freeze meant my feature had to be mostly done." Our releases ship on time and we do not miss any of our test or final release dates if we do, it is for something other than, blocker bugs weren't fixed in time or rawhide wasn't working The release under development is destabilized far less than it is today "unfrozen rawhide" is fully implemented and the main branch release under development is stable and can be reverted to (thus allowing us to ship on time) when regressions or other bugs are introduced in a given month rawhide was installable and usable for regular desktop use 90% of the time. The question of who our target audience is or what the Fedora distro is for are answered and established. When these topics come up they are discussed in form of "we should change from X to Y" not "how about X or Y or why do we need to decide?".

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.
poelstra	Wider integration and use of the community portal Establish a clearer vision of who this portal is for and what how it will be used by more people Actively use and take advantage of it I know the portal does a lot of cool things, but I'm not sure who its intended audience is We can accurately answer questions like (beyond just counting FAS accounts): Is community participation growing or slowing? Is the Fedora Project attracting new people? Are they staying? What makes them stay? How involved are they? What is causing them to leave? The Fedora Project is known as a welcoming software community that helps other people grow. It is considered the "gold standard" for how well run open source software projects work. This same standard is also applied to the way we create our distro and how it is received by our targeted audience. We have an established way to measure this

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.
poelstra	Completely (as in nothing deferred to Fedora 14) implement the "unfrozen rawhide" proposal Update our documented release process and freeze policies so that more people can understand them and find them I'm planning to help with this one. Ideas on how to measure the success or failure of this is welcome. More communication about upcoming schedule milestones and what the expectations are around those milestones I'm planning to help with this one. Ideas on how to measure the success or failure of this is welcome. Release Criteria for each release: Alpha, Beta, and Final I'm planning to help with this one. in order to write good release criteria we need to know what the goals are for what we are creating and releasing To to this we also have be able define what success is for our releases. I'm suggesting something beyond what we have now and have some drafts in progress Clear instructions and a guide so that anyone can write a test for the automated QA testing framework. Established processes for adding newly written tests to the framework and seeing the results. The automated testing framework tells us more often than not when rawhide is unusable on a particular day vs. someone discovering it on their own. A place for fedora-test-list posters to check first.