1 files changed, 64 insertions, 0 deletions
diff --git a/doc/admin/administrator_guide.md b/doc/admin/administrator_guide.md
index f21c55327..c233d8564 100644
--- a/doc/admin/administrator_guide.md
+++ b/doc/admin/administrator_guide.md
@@ -196,6 +196,70 @@ The installation script was originally designed for a small hardware server behi
 1. `service apache2 reload`
 1. Open your domain with a browser and step throught the initial configuration of $Projectname.
 
+### Server Roles
+
+$Projectname can be configured in many different ways. One of the configurations available at installation is to select a 'server role'. There are currently three server roles. We highly recommend that you use 'standard' unless you have special needs. 
+
+
+#### Basic
+
+The 'basic' server role is designed to be relatively simple, and it doesn't present options 
+or complicated features. The hub admin may configure additional features at a site level. 
+This role is designed for simple social networking and social network federation. Many features 
+which do not federate easily have been removed, including (and this is somewhat important) 
+"nomadic identity". You may move a channel to or from a basic server, but you may not clone 
+it. Once moved, it becomes read-only on the origination site. No updates of any kind will be 
+provided. It is recommended that after the move, the original channel be deleted - as it is 
+no longer useable. The data remains only in case there are issues making a copy of the data. 
+
+This role is supported by the hubzilla community.
+
+#### Standard
+
+
+The 'standard' server role is recommended for most sites. All features of the software are 
+available to everybody unless locked by the hub administrator. Some features will not federate 
+easily with other networks, so there is often an increased support burden explaining why 
+sharing events with Diaspora (for instance) presents a different experience on that network. 
+Additionally any member can enable "advanced" or "expert" features, and these may be beyond 
+their technical skill level. This may also result in an increased support burden.
+
+This role is supported by the hubzilla community.
+
+#### Pro
+
+The 'pro' server role is primarily designed for communities which want to present a uniform 
+experience and be relieved of many federation support issues. In this role there is 
+**no federation with other networks**. Additional features **may** be provided, such 
+as channel ratings, premium channels, and e-commerce. 
+
+By default a channel may set a "techlevel" appropriate to their technical skill. Higher 
+levels provide more features. Everybody starts with techlevel 0 (similar to the 'basic' 
+role) where all complicated features are hidden from view. Increasing the techlevel provides 
+more advanced or complex features.
+
+The hub admin may also lock individual channels or their entire site at a defined techlevel 
+which provides an installation with a selection of advanced features consistent with the 
+perceived technical skills of the members. For instance, a community for horse racing might 
+have a different techlevel than a community for Linux kernel developers. 
+
+This role is not supported by the hubzilla community. 
+
+### Techlevels
+
+Techlevels is a unique feature of Hubzilla 'pro'. It is not available in other server_roles, although it expands on the concepts introduced in $Projectname 'basic'.
+
+We've implemented several different mechanisms in order to reduce the apparent complexity and learning curve presented to new members. At the same time, we do not wish to limit any functionality for people who are able to grasp some slightly advanced technical technical features. The first mechanism was to move several features to an optional 'Features' page where they could be enabled at will; with the default interface kept somewhat lean. 
+
+The problem we had now is that the number of features began to grow dramatically, and the Feature page is daunting in possibilities. There are also features present which probably should not be available to all members, but may be extremely useful to those with technical backgrounds.
+
+The techlevels seeeks to remedy this by grouping features within different levels of technical ability; starting at 0 (uncomfortable with technology), and up to 5 (Unix wizard or equivalent).
+
+When a new member registers, their account is provided a techlevel setting of 0. On the account settings page they may change this to any available level. A higher level opens more advanced features and possible interactions.
+
+The account administrator may also lock a particular level, lock a maximum level, or change/re-arrange the features available to any level. Those with the minimum level are typically not very exploratory and are unlikely to discover the advanced modes. This is by design. Those that look around and desire more interactions will find them. In the absence of administrator defaults they may choose any level. As they look at the features available to the level in question, it is generally expected that they will discover some features are beyond their comprehension and it is hoped they will back off to a level where the interface and features are comfortable to their skill level. This is somewhat experimental at present and for that reason is not part of the 'standard' server role. The standard server role is preset to level '5', and the basic server role is preset to level '0', with no possibility of change. Members in these roles may find themselves overwhelmed or underwhelmed by the feature set and complexity.        
+
+
 ### Service Classes
 
 Service classes allow you to set limits on system resources by limiting what individual