5:21 p.m.
Hi folks!
Below find a summary of yesterday's meeting. You can also read it in
blog format at http://fedoraserver-wgblog.rhcloud.com/?p=32 .
Below the summary, you'll find the meetbot links if you'd like to read
the raw logs.
If there are any mistakes in the summary here please edit as appropriate
on the wordpress blog: http://fedoraserver-wgblog.rhcloud.com/wp-admin
~m
Meeting Minutes
===============
Agenda
Our agenda was set ahead of time on the mailing list.
* Goals for Server Role Installation
* Personas
* Server Lifecycle Proposal
* Updates and Testing Proposal
* Server Role List Proposal
* Installation Roles vs. Post-installation Role Assignment
Members Present
* sgallagh
* nirik
* mitr
* simo
* mizmo
* Viking-Ice
* davidstrauss
Goals for Server Role Installation
----------------------------------
We went over the server role installation goals document that we started
in the piratepad last week. Nirik suggested another goal which we put in
the deferred list for now:
I wonder: do we want to add: ‘off line’ installs? [...] use case
would be a secure site that can’t access the internet… they want to
install a server + roles without direct net access.
sgallagh remarked that for users in need of this goal, “as a workaround
they can always have a local mirror too.”
“… if we support manually-managed local mirrors,” replied mitr. “It’s
not a huge problem but worth keeping in mind == adding to the deferred
list.”
“As long as you can run mirrors or build custom ISOs, it’s easy,” added
davidstrauss.
Nirik also mentioned, “If we support this case we need to make sure
those tools work, etc.”
“I have run into problems with mirror support, for sure,” davidstrauss
agreed.
As mitr brought up mirror management as an issue here, sgallagh asked
him, “Do you want to add mirror management as a deferred goal as well?”
“I view “mirror” as an implementation detail in this discussion => N/A,”
responded mitr.
Simo suggested, “Mirror management could be a product role, actually.”
“True,” replied sgallagh.
We agreed to accept the server roles installation goals document.
Personas
--------
I posted a link with some introductory information from the mailing
list: Fedora Server Personas / Target Users. I also posted a placeholder
document on the wiki without much of anything useful in it yet.
“So I don’t think a persona is, ‘person who wants to install a directory
server,’” I said.
“Let’s decide here how we want them to appear first and then take the
brainstorming to the list,” suggested sgallagh, adding “And should we be
deciding on Personas for the Server Platform or for the Roles (I’d say
defer the latter).”
“I think they should be much more broad than roles so it’d be for the
platform,” I responded.
Simo said, “I think we just need to discuss the logistics of this goal.
How many personas? Do we want a hard limit so they are manageable?”
“I think 4-6 is reasonable, better to have less,” I replied to simo.
“I think we need first generic personas,” said simo, “to investigate the
interaction with our basic product.”
mitr said, “I’m ambivalent on personas – it’s a convenient way to
describe the span of the user base but we need to be careful to avoid
unwanted correlations (“installation is only done by inexperienced
people” and the like.)”
davidstrauss expressed some concern as well, “I’m not a huge fan of
using personas here unless they express something beyond the laundry
list of other requirements we’ve been drafting.”
“I think they’re meant to be the litmus test for those requirements,”
sgallagh replied. “If a requirement doesn’t solve a problem for a
persona, we’re either missing a persona or the solution is out of scope.”
mizmo also responded to davidstrauss, “I would like to use the list of
personas to go out and do actual user research, build relationships with
a cross-section of the user base we’d like that we can then go back to
for feedback on ideas etc. So I’m not talking about personas as a 1:1
with a use case. I’m talking more about personas as the kinds of people
who would use or be affected by this product.”
“I guess I’m partly less into them because I’m basically in this group
as a persona. :-) ,” davidstrauss responded. He volunteered to help
write up his own persona and be interviewed for that portion of the work.
nirik asked, “So, for example: ‘application developer’ could be one
right? someone who wants to build server applications? Or ‘home/small
business’ where they are constrained to one server/limited resources? Or
‘enterprise datacenter’ where they want to roll out many server
instances and automate.” [as an aside, I missed these during the chat
and they are all fantastic examples, and I'm totally going to steal them
for the first draft of the personas document! -mo]
“Let’s not start discussing individual proposed personas here, though,”
sgallagh said.
At sgallagh’s suggestion, I took an action item to create a template for
the personas. I do already have one with Red Hat branding that I will
repurpose into wiki format. :)
“Then the idea is that we look at those moving forward to decide
things?” nirik asked. “How it will affect them or the ones we care about
more?”
“I think this should become the litmus test for anything we put as a
formal requirement on Fedora Server,” sgallagh responded, “If it does
not address the needs of a defined persona, it’s probably not a proper
requirement.”
“Exactly. e.g., this feature is great for persona A, but will it
negatively impact persona B’s workflow?” I also answered, “Once we have
the set of personas i can start finding folks who roughly fit the roles
and interviewing them to get more information about their workflow, etc.
and get their feedback on our ideas.”
nirik said, “My one concern is that do we have time to do that? With our
January deadline?”
“We have time to write up the initial set of personas, I think,” I
replied. “To refine them based on the research will take longerm but is
not needed by January.”
“Fair enough,” nirik responded.
Viking-Ice asked, “Where do you want to place those personas in the
definiton of server roles or in the prd for the applications or…”
“We’re not discussing role personas,” sgallagh answered. “We’ve agreed
that those are a separate topic. These are personas for the needs of the
platform itself, not the specific services it offers.”
simo added, “Personas are part of the discovery phase to come up with
requirements, so it belongs to the discovery phase, before PRD, before
Roles.”
“Doesn’t really matter,” mitr also said. “E.g. we can keep them on the
wiki and use them for the PRD but not include them in the final PRD.”
Viking-Ice responded, “Yes and the personas for the platforms are
administrators.”
“Yes, absolutely,” sgallagh confirmed. “But as we discussed yesterday,
that’s not a homogeneous group. We want to define the different types of
administrators.”
So the conclusion of this topic is that we’re going to have a set of 4-6
personas representing the types of users who would use or would be
affected by the Fedora Server Platform. I will send out a template and
some initial draft persona ideas, and everyone on the list will respond
on the list with feedback, corrections, and their own ideas for personas.
Server Lifecycle Proposal
-------------------------
We very briefly discussed the following points with respect to this
topic (in reference to the Server Lifecycle Proposal):
* FESCo has a ticket on releases and lifecycles: FESCo Ticket #1202
(from nirik)
* We do not agree with each other on how the platform is composed.
* We do not have any idea if the Base working group’s plans will allow
us to go with this plan.
* Package maintainers are allegedly concerned about the amount of work
this plan will create for them.
* We are deferring lifecycle discussions for a week.
Updates and Testing Proposal
----------------------------
This was nirik’s proposal as an alternative to tweaking the lifecycle
process.
We skipped the topic: “I’m ok deferring it until we know what we are
shipping/doing,” said nirik.
Server Role List Proposal
-------------------------
I took the list of server roles in the server roles proposal document
and added Viking-Ice’s list of roles from his working document so we now
have one consolidated list of roles.
nirik asked, “So, what are we discussing exactly? the entire document?
or just the roles part?”
“I guess we should figure out,” I responded, “1) How many roles will we
support initially, and 2) identify which of those roles will be in the
initial supported group.” I also found a document where we’d agreed to
start with 1 to 3 roles initially and pointed that out to the group, and
we agreed to start with 3 and go from there.
In response to the list of items, mitr said, “That’s a fairly
comprehensive list of possible items. I’m not sure that all of them are
actually roles (e.g. backup, containers may be part of the shared server
infrastructure.)”
“‘Failover Clustering Services Server Role’ isn’t a role,” davidstrauss
remarked. “It’s something particular to specific other roles. Failover
is very role-specific. For example, failover for MariaDB is completely
different than for Kerberos or Samba. Throwing in a bunch of cluster/HA
utilities isn’t a useful fulfillment for HA needs.”
Viking-Ice responded, “Not really + other OS has those defined as roles.”
“As I’ve stated before as well,” sgallagh added, “I’d rather see a
“Domain Controller” role than necessarily an LDAP role.”
simo said, “Some of these roles look a bit too generic to me.”
“Yeah, the “Network Services” role is wrong, I’d say,” sgallagh added to
simo’s comment.
So the main concerns over the list of roles was that some were too
specific, some were off the mark, and some were too generic. There isn’t
a lot of consistency to the level at which each role was written.
Sgallagh pointed out, “Let’s not be too harsh all at once, though. This
is a good place to start.”
Viking-Ice proposed a way forward, “We really should push the roles
through the ‘Server Role Process Agreement’ if the intent is to use the
stage gate approach.
https://fedoraproject.org/wiki/User:Johannbg/FOSSP#Server_Role_Process_Ag...
“Certainly, we should only choose a shortlist of roles *after* defining
personas, right?” asked davidstrauss. “If we’re going to the trouble of
defining target users, shouldn’t we use that work here as a tool?”
“That’s ideal,” I responded.
simo asked, “How specific do we want roles to be? For example
‘Lightweight Directory Services Server Role’ seems to be quite specific
to a task (although I do not consider samba4 lightweight,) while
‘Network Services Server Role’ seems quite broad and in my view would
contain the lightweight services from a semantic point-of-view.”
“I think the first ones we should do should be somewhat generic,” nirik
replied, “to cover as many folks as we can…”
Simo answered, “I guess I need an example to understand what that means.”
“I think we really need to talk about personas,” sgallagh said. “We
might want to focus first on ‘Things people already want to use Fedora
for,’ so that we can improve their experience and use them to expand our
influence.”
“That’s independent from the personas to a degree,” said simo.
sgallagh answered, “Not if we select “People currently using Fedora as a
server” as one of our targets. :) ”
“We could also focus on ‘building blocks’… ie, ‘apache web server’ could
be used by many other higher level roles?” nirik suggested.
Simo agreed, “Indeed. Some components can be used by many roles,
possibily conflicting roles. So having a ‘Web Directory Services Server
Role’ makes little sense to me.”
sgallagh suggested that discussion of specific roles should be taken to
the list.
Viking-Ice pointed out, “Well people seem to be fixating on the M$ admin
so I defined the roles based in theirs and trust there are few more
there that dont make absolutly no sense ;) ”
“Well, I’ve mentioned a couple times that our path to wider adoption
involves getting people to leave their MS comfort zone,” said sgallagh.
“But that doesn’t need to be our only goal, or even in the first set of
them.”
simo asked one final clarification question, “Do we define roles based
on very generic use cases, or do we want to base them on well-defined
use cases?”
“Personas should be abstract and focused on end goals. Roles should be
well-defined, supportable ways of achieving those goals,” proposed
davidstrauss. “A persona might want an office network server that does
DHCP. A role might be a network services server with ISC DHCP, etc.”
“I think that persona is too specific,” I pointed out. sgallagh and simo
agreed.
Viking-Ice asked that people read his stage-gate process write-up.
Installation Roles vs. Post-installation Role Assignment
We didn’t have time to discuss this topic.
Meetbot Minutes
===============
Here is the official meetbot meeting minutes with links to the full raw log:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-19/fedora-meeti...