| 7 | | 1. Plan integration of Crit Path/MFPL |
| 8 | | * Question: defining an entity for CP as it works with MFPL. |
| 9 | | * Question: defining the user experience as they request a feature provided by CP and MFPL. |
| 10 | | * Question: How do we keep the connection/presence of Critpath within the Mayfirst structure? |
| 11 | | * do they go to our website to create a new list, does it link to Mayfirst, is there a distinction between what is provided to CP users vs. general Mayfirst members? |
| 12 | | * or how can we integrate our website with Mayfirst effectively? |
| 13 | | * Question: what type of control or limitations will CP users have that they are unaccustomed to that we need to alert them to and provide support for? i.e. who creates or is allowed to create a new list? are there limitations to how many lists one person can create if they are a CP user? Does this distinction between CP user and MFPL user even matter? |
| | 7 | We need a system that achieves the following goals: |
| 15 | | 1. Setup Debian/MFPL system on dissonance (temp IBM server) |
| 16 | | 1. Move DNS to MFPL DNS servers |
| 17 | | 1. Move mailman lists |
| 18 | | 1. Transition one organization's web/email on new server |
| 19 | | 1. Mass migrate all organizations |
| 20 | | 1. Reformat axiom, move from dissonance back to axiom |
| | 9 | * Allows CritPath to create and delete services on their dedicated server (not just control panel items, but being able to create new memberships and hosting orders as well) |
| | 10 | * Maintain identity of CritPath within May First/People Link |
| | 11 | * Coherently transition from CritPath's model, in which individual contacts are assigned different services as requested, but they are not organized by parent organization, to [wiki:mfpl_data_model MFPL's model]. |
| | 12 | |
| | 13 | Following are changes to the MFPL system that I think we'll need: |
| | 14 | |
| | 15 | * MFPL extends our Control Panel to include a special server-maintainer section. The server-maintainer section allows certain authorized users the ability to add/delete/modify memberships and hosting orders on a given server. |
| | 16 | * MFPL extends our Control Panel so that when users log on, they can get a different theme depending on the server they are hosted on. CritPath and MFPL can collaborate on a theme that incorporates both organizations |
| | 17 | * MFPL adds a new field in the ticket tracker for partner which defaults to MFPL, but CritPath is an option. Users who fill out tickets can choose CritPath, or anyone can re-code the ticket based on the content of the ticket. CritPath support people subscribe to an RSS feed of all tickets coded to CritPath. Either MFPL or CritPath answer queries. |
| | 18 | |
| | 19 | Following are steps to take for the transition: |
| | 20 | |
| | 21 | * MFPL creates a virtual server on ottorene dedicated to CritPath (this option will use less electricity and be much easier for us than using the IBM given to us for this purpose). |
| | 22 | * We fully test the system for creating new accounts before we transition anything |
| | 23 | * Transition: DNS, mailman, web/email accounts |
| | 24 | * Reformat axiom and transfer all services to axiom |
| | 25 | |
| | 26 | Following is a use case for a new CritPath user requesting services: |
| | 27 | |
| | 28 | * User fills out form on CritPath page |
| | 29 | * CritPath receives email and decides to provide service |
| | 30 | * CritPath admin logs on to MFPL Control Panel and creates membership/hosting order |
| | 31 | * New user is notified with canned email (written by CritPath) that explains our relationship |
| | 32 | * Email includes link to MFPL control panel. When user logs onto control panel, they see CritPath/MFPL theme |
| | 33 | |
| | 34 | Following is use case for an existing CritPath user requesting additional service |
| | 35 | |
| | 36 | * If they want a new email list, DNS entry, or email address then they use the MFPL Control Panel to create it themselves (as many as they want) |
| | 37 | * If they want a new web site, they contact CritPath and CritPath creates a new hosting order for them. |
| | 38 | |
| | 39 | Following is a use case for a CritPath user request support |
| | 40 | |
| | 41 | * They fill out a ticket on the MFPL support system. |
| | 42 | * They don't bother with the partner field |
| | 43 | * MFPL member sees ticket and re-codes to CritPath and leaves a question/comment on the ticket |
| | 44 | * CritPath support person gets RSS feed, sees ticket and contributes to the solution |
| | 45 | * Either MFPL or CritPath person resolves ticket. |
