On 09/13/2016 03:02 PM, Stephen John Smoogen wrote:
On 13 September 2016 at 14:41, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
> On Tue, Sep 13, 2016 at 06:21:46PM +0200, 'Dominik Perpeet' wrote:
>> Summary: It is easy to download, configure and install Fedora Server for
>> [insert list of standard use cases here, e.g. LAMP, container image
>> registry].
>
> What about phrasing this as an output (or set of outputs, even -- the
> media, docs, webpage, tools), and having "1000 new Fedora Server
> installations using our standard use cases by 2018" as the outcome? (Or
> some other number -- I picked that out of a hat. Measure by survey of
> users or by opt-in data gathering?)
This is where I feel a cycle from left to right is needed to get to
the rigth to left. We could put up multiple outcomes which could be
'measured' but only if we discuss and agree to how we are going to
measure them.
I mean to meet the 1000 new Fedora server.. or some other number will
take that we have some sort of census program which is run or a string
in the dnf update which says which product the os was installed with.
Both of those are considered by various people as overly invasive and
will argue that they should only be opt-in etc etc.
First of all, thank you very much for running the Server SIG meeting yesterday,
Robyn!
I'm reading through the transcript and I *think* there was a little confusion
about what is an Outcome vs. what is an Output. An Outcome is still an indirect
result of our efforts, but one that is theoretically measurable (not necessarily
with existing tools and metrics). An Output is a concrete deliverable or
artifact that we produce.
So "It is easy to download, configure and install Fedora Server for [role, e.g.
setting up a fileserver]" is *close*, but how do we measure "ease"?
So let's take that fileserver example. An Outcome we may want is: "Users of
Fedora Server Edition can share files with clients of multiple popular operating
systems." The associated Output for that could then be one or more of "Samba
Server Role", "NFS Server Role", "AFS Server Role", etc.
From there downwards, we'd have Activities which could be "Produce a role
definition for a Samba server" and "Produce a Cockpit plugin to manage a Samba
server". Similar activities could be created for each desired role.
I have a work-in-progress Kellogg Logic Model for this now available at
http://kolinahr.herokuapp.com/edit/57d05a6984338834000515c9 (and I'm attaching a
screenshot of my current state). This is just a prototype of the Kolinahr app
that a friend of mine is writing for Fedora to use and it's hosted on the free
tier of Heroku at the moment, so please be patient if it's slow. At the moment
it requires a Google Account to sign in and view models; I'm working on finding
it a permanent home in Fedora Infra and it will be hooked to FAS instead at that
point.
Please offer feedback on the current state, particularly additional content in
the same style. (If you log in to the Kolinahr instance, I think you should be
able to just edit it directly, so feel free to make new additions at will, but
please don't delete anything without first discussing it on the list).