>Hi John!

>As Fedora Server is a community project driven by whoever is
>interested in doing the work, certainly we'd like your help on things.

>I want to clarify first that I think you have the wrong idea about
>what a "Server Role" is. The idea is for a server role to be a
>singular task for the server to perform. A machine may be assigned
>multiple roles, but they should be managed individually.

>I don't see us having a "Small Business" role, in part because that
>implies many different things to many different people. Instead, we'd
>be talking more about roles like "Domain Controller", "ownCloud
>Services" or "OpenStack Node".

>We *do* need to start talking about whether we want a graphical option
>for Fedora Server 22. We expressly deferred that decision because our
>initial target was focusing on headless systems.

>John, would you mind running down the use-cases you have for having a
>local graphical login on your servers (as opposed to remote services
>like SSH or web-based configuration tools like Ajenti or Cockpit)?

Okay, I understand. Well I think you do have a point there. It would kinda break the flow of the list in the installation process (Now thinking about it). However I am just now looking at the chat log of you all talking about having multiple roles in one single physical server (If my context clues are right).
I know for the beta and I think the full release you want just the base + essential server roles, and then later down the road your going to define more. How about you leave the essential roles for now that way you will have somewhat have a base to go off of other servers (ownCloud, Round Cube, HPC roles, etc.), BUT create a template so that members of the community can create there own roles and add it to a repo list. Kinda like having the Play Store on Android but for servers. I know you are still in Alpha phase but this is just something to consider, but I digress. 
As for use-cases, I see it like this:
Case 1: Migration of servers.
Ex: Server A is a old model so were going to migrate the configuration to the new Server A. (You really have to be there physically there to mess with hardware / networking)
Case 2: Install / Remove Hardware.
Ex: Faulty RAM / CPU / Hard drive (That is not hotswapable) you want a quick way to identify the server and turn it off from a KVM inside the rack. (Not all company's will have a dedicated machine to SSH or go into a web-browser to configure these things. They may still have KVM's inside there cabinets.)
Case 3: Installation of server software (Open Source AND Proprietary).
Ex: Bitnami + your appliance, a appliance software stack where you can install it in a VM or locally inside a desktop. However you need to have a GUI to configure / start/stop / view logs to install locally. (They still have there own web interface in a browser but you still need a GUI to install it.)
Sidenote: Case 3 ~ When you install Bitnami + your appliance locally it uses the Container feature like Docker so it does not interfere with other configurations in the same server.
When I was doing my research at my University, I opted to give the user to use either the Ajenti, because it was a quick overview of your server / services that you were running. AND I wanted to have a configuration / overview control panel locally (That I was going to build in-house) so that you could have more advanced outlook on your server as well as local documentation, Hardware Install / Uninstall Wizard, and some other helpful stuff for the person. Because I figured that a small business didn't have a IT staff so it had to depend on ques from the software logs / messages and the documentation. But you could pretty much run the server from either both or one of them just fine...
So those are my cases, hope this was some of help to you. :)
John