Draft Product Description for Fedora Workstation

[Ray Strode]

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