Workstation PRD approval

[Marcel Oliver]

Matthew Garrett writes:
 > Attached.

Some comments on this proposal: From my POV what is missing is the
academic/science/engineering workstation use:

* Use of a variety of standard, in-house developed, and/or third party
  tools to run simulations, analyze data, visualize results, etc.
  Examples are R, Scipy, Sagemath, gnuplot, ... from standard
  repository, as well as Matlab, Mathematica, IDL, ... from the
  proprietary universe

* Complex workflows involving a variety of different tools

* Users depend on window manger for managing windows (it cannot be
  assumed that applications are nice/self-managing in any way, often
  no IDE or several IDEs as mixture of tools is too diverse).  Typical
  scenarios are lots of terminal windows displaying text diagnostic
  output of long-running jobs on local or remote machines, lots of
  visualization windows created by various tools - often home-brewed,
  all mixed with editor windows for program or glue code,
  wordprocessing, LaTeX, web, several open documents in PDF viewer,
  email, everything is part of the same workflow.

* At least on centrally managed machines software selection is close
  to install everything as academic users tend to have very different
  ideas of what software they should use, so system administrators
  will install a lot.  Disk space is cheap, but it's taxing on
  menus/app selection.

* Use of big/high-res/multiple screens in various geometric
  configurations; also: projector use for presentations needs to
  absolutely work in all circumstances (which it mostly does nowadays,
  from my observations at least on par with Windows/Mac now).
  Especially in academia on tends to encounter a great variety of
  different projector generations of varying quality, typically
  without the chance of much prior testing, so it absolutely needs to
  work blindly.

* Various roaming scenarios need to work (VPN, eduroam which is
  PEAP/MSCHAPv2 authentication).  This should in principle be a
  non-issue, but I mention this because of recent problems with both,
  so I get the impression that QA in this area is not very strong.

Particular challenges for the desktop:

* How to unclutter menus, make entries non-ambiguous?

* How to reliably find a particular window if you have 10 terminal
  windows each displaying number columns?  (This is where Gnome 3
  falls flat, for example.)

* How to efficiently navigate to windows on big/multiple screen
  setups?

* How to efficiently manage windows on big/multiple screens?
  (maximize, edge snap is usually doing the wrong thing.  Vertical
  maximize works usually better, good tiling strategies???)

* Good workspace switching, keep child windows on their proper
  workspaces even if they pop up in the background

* Taskbar or taskbar-like behavior for raising single windows without
  disturbing the visual context by overview mode.

Further comments:

* For big server/large workgroup installations, Fedora is probably too
  unstable by definition.  I have only ever seen either RHEL/CentOS or
  OpenSuSE used in this context.  So going for serious stability is
  probably out of scope, and conflicts at some level with the need to
  get timely updates on fast-moving software.

* From the draft: "This would include items like theming and making
  sure we offer a consistent accessibility story across different
  development toolkits." From my POV theming plays no role at all so
  long as the basic workflow requirements are met.  Also, "consistent
  accessibility" I see more on the side of a consumer product.
  Consistency is nothing that Fedora can achieve at the level where it
  would really be useful, so what is more important is accessibility
  and compatibility in the face of real-world inconsistencies.

* From the draft: "a requirement that any software that wants to be
  part of Fedora Workstation can run against Wayland or directly
  output sound to Pulse Audio".  I am not sure what that buys.  Yes,
  it would be a generally good idea to fix up software that violate
  these goals.  But that's a general (and worthy) Fedora goal.
  Especially for Fedora _Workstation_ I would see the requirement the
  other way round: can the base system be compatible enough so that I
  can get legacy code from back when Wayland was not even dreamed of,
  strange in-house developments, obscure toolkits etc. run at least in
  some way without running through impossible hoops.

* For compatibility with third party/commercial software, one should
  probably narrow down to specific needs.  From my perspective, these
  would include Matlab, Mathematica, Maple, NAG libraries, ifortran,
  IDL, and similar tools with a long and usually good history of
  compatibility.  But ideally the free software alternatives should be
  there and integrated well to reduce the need for commercial tools as
  much as possible while still acknowledging that people might have
  (legacy) needs which make it inconvenient or impossible to avoid
  proprietary software.  Other users might have completely different
  needs, so it would be good to compile a collection of wider
  importance.

Regards,
Marcel