On 9 August 2016 at 16:32, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
On 08/09/2016 04:22 PM, Stephen John Smoogen wrote:
> On 9 August 2016 at 15:56, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
>> On 08/09/2016 07:32 AM, Josh Boyer wrote:
>>> On Mon, Aug 8, 2016 at 10:10 PM, Jon Stanley <jonstanley(a)gmail.com>
wrote:
>>>> I’m quite concerned about the status of the Fedora Server Working
>>>> group after the departure of Stephen - he provided excellent
>>>> leadership and is definitely missed from the working group. However,
>>>> things seem to have fallen by the wayside since his departure. Perhaps
>>>> the members that are at Flock can meet and hammer out what the future
>>>> of the working group should be. From my perspective, there are a few
>>>> things:
>>>
>>> This would have been more timely last tuesday. Flock is over.
>>>
>>>> We need to go back to the initial PRD
>>>> (
https://fedoraproject.org/wiki/Server/Product_Requirements_Document)
>>>> that the working group was formed with and see if it’s still valid and
>>>> viable, or if we need to change it, and if so in what way? What does
>>>> that lead to in terms of deliverables?
>>>
>>> FWIW, there was a significant amount of time during the Flock PRD
>>> session on Server. You can see the resulting logic model document in
>>> this Council ticket:
>>>
>>>
https://fedorahosted.org/council/ticket/63
>>>
>>
>>
>> I've worked up the content that Josh recorded into something *close* to a
logic
>> model document using Taiga[1]. It's not perfect (the arrows are missing and
>> poorly substituted by tags), but it's helpful for visualizing.
>>
>> If all of the sitting WG could log in there and create a user, I'll add you
to
>> the editors of the board so we can modify it and work on adding Activities and
>> then Inputs.
>>
>>
>> For a little background, the idea is that we generate a PRD from right-to-left
>> on this model, then we will execute on it from left to right. At Flock, we
>> discussed the three right-most columns of the model, starting with the long-shot
>> Impact we want to have and working down to a set of Outputs we can generate in
>> order to get there.
>>
>> I think the first order of business is to take a close look as a group at this
>> existing content and decide if we need to modify it (add more Outputs, limit our
>> scope, etc.) and then we can work together on the Activities.
>>
>> Feedback greatly appreciated.
>>
>>
>
> I have a concern that:
>
> A growing, measurable number of startups and other SMBs pick Fedora
> Server for apps and services
>
> is not possible to measure... or that it actually is useful goal.
>
> 1) It is incredibly hard (I would say impossible) to measure size of
> usage of any our 'flavours'. I can sort of measure the usage of
> workstation because of the hotspot finder but it is at guesstimate
> levels. There are no tools and also a large pushback from various
> people for 'measuring' as it invades various views of privacy.
>
Well, that's not entirely true. If nothing else, moving to modules to replace
roles will likely have to come with new ways to report bugs; bugs that would
essentially be Server-specific. A marked increase in reported (and fixed!) bugs
that were Server-centric would be one way to measure usage in broad terms.
Another would be an increase in voluntary reporting (such as people talking
about it on social media, blogs, magazines, etc.) An increase there would
indicate (and catalyze) an increase in usage.
On the first part (new ways to report bugs). That would probably be
the best and would be helped that any tools we produce aim them to put
in bugs in the right spot so that the postfix RPM maintainer is not
getting random bugs about the mail module that they have no idea
about.
I would say for the voluntary reporting on social media we will need
to break out of cranky old server sysadmin crowd :). So any reporting
would be a sign of growth :).
> 2) If an equivalent or better way to measure usage as hotspot.txt
> comes into place for server and it is implemented without too much
> turn off... what does growing mean? What does the lack of growth mean?
> [IE if we don't see say N% end over end quarterly growth do we pack up
> and end working on server?
>
These are desired Outcomes. If there is a lack of growth, then we need to
revisit whether our Outputs are incorrect or insufficient and revise this
document. Outcomes are not the same thing as requirements or milestones.
OK I don't see how that makes an outcome anything more than the first
column but it must be useful to someone I am not seeing. [I say this
from the position of thinking Mission/Vision statements were useless
time wasters for years until I realized in some places they make
perfect sense.]
> 3) There does not seem to be good focus on who is our customer? Are we
> aiming at classical services who remove our sendmail and put sendmail
> 4 in place? Are we aiming at an ADHD dev crowd who take systemd out
> and replace it with their node.js init system they found this morning?
> Or one of the bactrian humps between those extremes?
>
This specific model doesn't talk to who are users are; that's a separate
question that was mostly resolved outside of this. Essentially we have been
putting our focus towards the small-to-medium business crowd; essentially the
set of people that will need some reasonably constrained number of machines
around. We're explicitly leaving the large targets out of the discussion for the
short term (those places for whom the word "orchestration" is known and
necessary).
OK this actually was useful to me because it can help me see how to
make the outcomes measurable.
So Fedora Server would be about helping the small office or home
office getting
set up first and foremost. Then we can build on that, but trying to conquer the
world right from the start would leave us right where we are today: paralyzed
with indecision.
> Does this input help any?
>
Of course. This is a discussion and if any part of the output we're generating
is unclear, it is *not* good output.
_______________________________________________
server mailing list
server(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/server@lists.fedoraproject.org
--
Stephen J Smoogen.