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_Agree...

“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-meeting-...