Collection of Ideas to discuss - roketi/roketi.github.io GitHub Wiki

This page is about to collect ideas regarding the functionality of Roketi in general and serves as a starting point for the first meeting of the crew:

Target Audience

  • Who are we targeting with Roketi?

How will you use Roketi in your setup?

  • easily setup vms as vhosts
  • Deploy with Puppet/Chef/Ansible/Packaging

What is the most important functionality for you as the operator?

  • easy vhost management
  • ldap + usermanagement
  • Billing management / Integration
  • Monitoring / Statistics
  • Backup / Restore
  • API
  • Easy Upgrade
  • Scaling

What is the most important functionality for your customers?

  • easy creation of accounts (mail, ftp, ssh, ...)
  • Self Service throughout the features
  • Monitoring / Statistics
  • Backup / Restore
  • API
  • Secure setup!
    • Use modern security configurations, such as Perfect Forward Secrecy, DNSSEC, and others

With which part of the functionality shall we start?

  • installation
  • account management
  • json api

User-Levels

  • What types of users will we have?
  • Are there "reseller" accounts needed?

GUI

  • Will we develop a "simple" application, or a fancy JS based one that just talks to an API?
  • +1 for FLOW application with JS api
  • Does it need to be PHP, or is f.e. Ruby or Python an alternative?

What technical base do you prefer for $roketiComponentX ?

Shall we just handle vHosts, or some kind of container system for the single websites?

  • chroot + vhosts
  • Docker.io: Have a docker per Webinstance/Website and make it Super-Portable. A feature which is not provided by any other Hosting Controlpanel. Would be a BIG thing!

Which software packages should be used to deliver the services?

  • Which webserver, mailserver, DNS server, ... shall be used?
    • I suggest using PowerDNS, because it can have different backends like MySQL.
  • Should those tools be "hardcoded" or shall there be single "connectors" so one can add a connector if he prefers $anotherTool?
    • Hardcoding makes live much simpler, but for some compenents it maybe could make sense to make it modular.
  • Application should modular, but for the first iterations i would prefer to define the debian standard tools as tools of choice.

On which technology should the GUI be based on?

  • Bootstrap + EmberJS?
  • Should be useable on a browser with JS deactivated.
    • I appreciate that too, but: depending on how "Application"-like the GUI should work later, this might be hard to achieve
    • Probably the (or some kind of) mobile first paradigma might be a approach here? You basically define a common denominator as foundation and use progressive enhancement to add more functionality and/or comfort?
  • Is a mobile solution mandatory (most likely responsive design approach)?

How should the project be organized and settled up? (the "less" technical part)

Project management
  • Any preferences for a special project method?
  • How to organize the workflow and team, etc.?
  • Maybe redmine as the project management tool?
    • +1 for redmine...
Conceptual stuff
  • General description / principles of the application (some kind of guidline, the heart and soul of the application :-))
  • General strategic thoughts (e.g. using already existing 3rd party open source parts vs. do-your-own)
  • Feature overview and priorization (e.g. as foundation for roadmap / concept)
  • Concept paper (at least a rough overview of features, target audiences / personas)
Usability
  • Thoughts about usability (e.g. about to probably using an UX-approach like "User Centered Design" or at least helpful parts of it)
  • How to document the GUI and design descisions (in my opinion an application requires a design manual of some kind to grant consistency)
  • How to test and justify design descisions (best practice, usability testing etc.)
  • If using a CSS framework like bootstrap: will help us to provide a good user experience or will it rather limit design decisions?