Hi, I think this is a pretty good starting point for our development direction, and sets the stage for us making positive progress in the new working group model. I do think we should keep it open to tweaks in the future as things play out, (at the discretion of the 9 members on the working group). In other words, I think it lays a solid outline for enabling us all to know which direction to go, but i want to make sure if it doesn't ever "get in the way". The working group should treat it as a living document that gets updated as necessary to reflect changes in the landscape. Some comments inline below (mostly nits): > Fedora Workstation PRD > > Mission statement > The Fedora Workstation working group aims to create a reliable, > user-friendly and powerful operating system for laptops and PC hardware. > The system will primary be aimed at providing a platform for development Extra space between "create" and "a reliable" s/primary/primarily/ > Target audience > General: > Programming Environment: web languages and tools, open source databases, IDE, > Compilers, debug tools, performance monitoring > Desktop apps should be sufficient to make this system the users's only computer. s/users's/user's/ While I'd certainly like us to aim more generally, I understand we have to have some focus, and given the technical pre-existing userbase this is a pretty good one. I think if we do a good job, we'll be able to attract all sorts of users outside of our prescribed target audience, though. > Case 1: Student > Engineering/CS student who needs a personal system for software class wor and > personal projects. Software class work may require particular tool chain > versions. Tries out new versions of open source applications when released. > Uses computer to play games. s/class wor/classwork/ I think this is a good one to target, because the student pool is a good place to recruit new contributors, and they're more likely to show up if we're making something they want to use. > Ability to play 3D games from commercial publishers distributing games for > Linux. makes sense. > Multiple developer environments i.e. school standard for class work, > latest tools for personal use. s/i.e./, e.g.,/ I guess this may also involve a virtual machine, if the class is standardizing on some windows tools. > Case 2: Independent Developer > Personal development system for an independent software developer doing > contract work or developing apps for a new opportunity. > > Desktop Apps: Up to date desktop with email client, browser, productivity > suite, messaging, and complete set of desktop apps and utilities. Desktop > apps should be sufficient to make this system the developer's only computer. s/and complete/and a complete/ s/make this/make this/ [... snip other use cases that sound good ...] > Other users > While the developer workstation is the main target of this system and what we > try to design this for, we do of course also welcome other users to the > Fedora Workstation. In fact many of the changes and improvements we expect to > implement for developers will be equally beneficial to other user segments, I think this is a really important point. Developers are users, too, just trying to get their work done. We should make sure the OS doesn't get in the way, and that it doesn't enforce artificial barriers to entry. Just because a user may know how the sausage is made, doesn't mean we should make them stuff their own (so to speak). And if a user/developer doesn't know the inner workings of Fedora, that's okay, too. We should be enabling the user to get the things done he/she cares about, not forcing them to learn the things we care about. There should be no "You must be this tall to ride Fedora Workstation" signs. > Overall plans and policies for the product > Bullet list numerating the technical goals and design principles of the product s/numerating/enumerating/. Though, maybe the fact that it's a bullet list is self-evident. How about just, "Technical goals and design principles:" > Robust Upgrades > Upgrading the system multiple times through the upgrade process should give a > result that is the same as an original install of Fedora Workstation. Upgrade > should be a safe and process that never leaves the system needing manual > intervention. safe and what? safe and pleasant? safe and reliable? It might be good to have some notion of frequency of updates. Do we keep them asynchronous? Do we ask rel-eng to queue them up into batches? I've seen some people complain about the "fedora firehose". Maybe that's a discussion for a different time, and not this document. I don't know. > Encapsulation of development environments [...] > Quality releases [...] > Container based application install [...] I'd reorder these so they are grouped better. Put Encapsulation and Containers next to each other, and put Quality Releases and Robust Upgrades next to each other, too. > 3rd party software Fedora Workstation will work with partners and ISVs to > ensure that their software can be easily installed on the system after > installation. This work will for instance include working with for instance > hardware partners to ensure users can install needed drivers directly from > these vendors. Fedora will not include any non-free software by default or > host any non-free software in our repositories. s/working/collaborating/ Drop one of the "for instance" fragments from this sentence. So we're not going to host and non-free software, but we are going to facilitate installing non-free software on the back end (by maintaining relationships with ISVs). What about facillating it on the front end? Are we going to do anything in the OS to help the user get to the non-fedora software they want access to? Access from the app installer? Help documents linking to instructions? I assume there are limits to what we can do, but I don't know what they are. > Fedora ecosystem integration [... snip good bits about integrating with output of other working groups ...] > Core Platform Components > The Workstation working group will define a set of packages that are > considered required be installed in order for the system to qualify as a > Fedora Workstation. Through policy users will be strongly advised against > uninstalling any of these packages and there will also be no option in the > graphical software installer to uninstall them. Any optional packages for the > Fedora Workstation can not obsolete or in any other way try to remove or > disable these packages. I assume, then, that there may ultimately be derivative projects that switch out some core platform components. I guess they won't carry the "Fedora Workstation" name. I guess, at some point, we should figure out the branding story there, though maybe that's a bridge we'll cross when we come to it? > These installed packages will together form the basis of the API and service > promises the system makes to 3rd party developers. Makes sense. We have to have a solid platform with well defined interfaces, if we want ISV buy in. [... snip sensible paragraph talking about minimum software integration requirements ...] > The working group will also specify policies in terms of branding, themeing > and desktop graphics. s/themeing/theming/ > Work model > We will at any given time try to have one major engineering effort underway > for the Fedora Workstation. The definition of a major engineering effort is > something that requires changes in a wide set of packages and tools. At the > same time we will be working on smaller projects to improve various aspects > of the distribution and also setting things up to be ready for the next major > effort. We will try to announce and plan these things well in advance, but > putting up a public timeline, but of course resources and changing market > conditions might make changes to the plans necessary on an ongoing basis. I think it's good the document formalizes that we should be focused. I do think the number of focal points may increase down the road if we scale up contributors. If that happens, we can update the text, I guess. > Marketable features > Each release is to have at least one item developed for it that we present as > a 'developer feature'. These items might be small or large in terms of the > effort behind them, but it they will be a core part of our messaging of being > a great first choice for developers. Examples include Software collections, > Developer Assistant, LinuxApps, new features in Boxes, IDE integration > and so on. I guess we should make sure that whatever that feature is, it's showcased on our live image (or at least testable on the image). > Other tasks for working group > The working group will also be responsible for defining release schedule > while also taking the needs of the other working groups into consideration > and the resources available from the Fedora infrastructure team. Should mention Fedora QA next to Fedora infrastructure. --Ray -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
