Task: Brainstorm implementation ideas for DU-Den.org
----------
* 4/11/2015
* keep in mind, these are initial brainstorming ideas.  Some may be found infeasible or undesired over time.  The list should be flexible as needed.
* The Wiki will become object #100000.
  * Lower object #s are reserved for special situations and porting from other MOOs.
  * Next object will be #100001.
* $wiki = Generic Wiki
* .password property will always be !r (not readable)
  any physical addresses and email addresses !r also for safety
  any phone numbers !r
* all other .properties should be +r as much as possible
* people in the Wizard role will be able to change R on an object
* multiple ownership
* everything should be relocatable
  * in case we decide to reassign an object #
    * for instance, a renumbering of the database for a core
* all literals should be stored in a property so the code doesn't need to be touched if referenced objects get moved
* $list = Generic List
* $user = Generic User
* #2 = Jeanne - Jeanne McWhorter in honor of DU's initial founder
* #9919 = MattWright
* #12972 = CindyT in honor of Cindy
* #16759 = Generic Enhanced Lecture
* A user has a certain number of "votes" they can give to, or take away from; another user, a list item, and so on
  The user's voteCount is a maximum; they don't have to assign either none or all of the points
  For instance, if User A is asked whether User B should be elevated to the next role, and User A's voteCount is 5, then they can:
     take away 5 points to indicate "Strongly No"
     take away 3 points to indicate "Somewhat No"
     take away 1 point to indicate "barely no"
     give 1 point to indicate "barely yes"
     give 3 points to indicate "somewhat yes"
     give 5 points to indicate "strongly yes"
  Don't worry, assignments of -4, -2, 2, and 4 would be possible too
  Generally a user is assigned a voteCount based on their role
  In case a race is running too close, an item being voted on can be given a multiplier, which then multiplies by that multiplier the number of votes 

a user can assign
    So for example, if User A's allotment is 5, but on a scale of -5 to 5 the race is running too closely, then the item's multiplier can be set to 2 

instead of 1.  Now, the voter can assign up to 10 points either way instead of 5.
  In the case of role points, once the user has been given a certain number of points (that haven't been taken back), then they are eligible for the 

next role.  Say they're a Builder and the vote indicates they should be a Programmer.  Then the issue goes to those who already have the 

ProgrammerApproval role.  A similar process then allows the ProgrammerApproval group to approve or deny the actual change.
  Once a person is given a role, their voteCount as of that time is saved; however, changes to the voteCounts are still allowed.  There should be a 

threshhold a bit lower than the one required to achieve the role, below which the user goes before the Approvers group for evaluation
* wiki pages are dependent upon the wiki object to which they are attached
* everything else, including the wiki itself, is assigned an object number
* all code should be +R (readable)
* a wizard can set a verb -R, but should clearly document the reason that code should not be readable.  We are, after all, a distance EDUCATION 

service.
* $list will represent something like a database table
  * has a list of column names
  * for each row, has a list of values for the columns
  * possibly do away with in-MOO values for all of this and just look them up in an actual db table as needed
* $generics properties dereference $items.  For instance, the value of $generics.generics is the object number of the "List of Generics" object
* there should be a child of $list representing the list of development ideas
  for very simple ideas, the details can be stored on this object
  for more complicated ideas, more manageable pieces of the information can still be store on the object; longer or more complex information should 

be put on a wiki page, then the object can be given a reference to the wiki page
* each item on the ideas list should have an assigned point value
  for now, each user can take away a point, decline voting, or give a point to each idea, until we flesh out this voting process
  we should be able to work on those items which have the most net votes for "yes"
* The question of assigning a specific privilege to a user (independently of their role) can be put to a vote, too.
* Every object will default to being licensed under the GPL.  Its owner can change that to either the LGPL or Public.
  Everything must be GPL, LGPL, or Public
  The goal is that anyone should be able to get a copy of the current state of the system at any time (minus the passwords), and at any time be able 

to use that copy to expand the system in their own way, or resume the system if somehow everyone else is gone.
* We should have 3 staging levels: Sandbox (anyone can change), Development (only certain roles or people can change), and Production (almost noone 

can change)
* We should have the same 3 staging levels, for "MetaProduction", "MetaDevelopment", and "MetaProduction" where we discuss changes
* On Sandbox, almost everyone has the ability to make changes, except to absolutely critical items
* A wizard effectively has an infinite number of voting points on any issue, so they can give whatever number, or take whatever number.
* The first idea to vote on should be "This DU-Den project is worth pursuing."
  * For now wiki users may vote on an item by editing its page and adding their name with "+1" or "-1" or "0" and an explanation of their response.
  * Once the voting process is managed, this would be handled by a Voting Object instead of by directly editing the text.
* A list should be unreadable only for an unavoidable reason, such as passwords and security
* We'll want a messaging system.
  - Private messages
  - Group messages
* Cindy Tallis' page at http://www.primenet.com/~ctallis in the Internet Archive should be reproduced on DU-Den's server in honor of Cindy.
* We should use a Model-View-Controller paradigm if possible
  * A user can have multiple views open at a time.
* Each person chooses their view(s).  Such as,
  - VRML
  - Web with/without graphics/scripts
  - Text with ASCII art
  - Text without ASCII art
  - Descriptive (text plus extra descriptions of items that would be visible/audible)
  - Languages including Esperanto
  - Without audio (but don't describe the audio, just omit it)
  - Stick figure interface
  - Cartoon/drawn interface
* Integrate with Facebook, Twitter, Google+
* extra restrictions are only put one someone for serious reasons, never as a joke
  when done, that person can still contact people with the ability to lift the restrictions (due process)
* helpme -- pages connected people who have selected to be considered helpful
* users gain helpfulness points, either by asking or by answering questions
* mentorship
* mentorship points
* File Utilities allow access to files on disk
  use $list to show the list of files (in order reuse existing functionality, don't reinvent any wheels)
  including ability to run executables on the server
    only with correct priviledge or membership in a role with correct priviledge
* Tutorials
  Help displayed one screenful at a time
* Standard form for user documentation
  * Users can comment on the documentation
* Standard form for code documentation
  * users can comment on the documentation
* Roles
  Guests, Visiting Student Player Objects (VSPOs), Players, Builders, Programmers, Managers, Wizards
* Areas
  Managers have areas
  User Control, Building Control, Code Control, Documentation Control, ... ?
* Sub-Roles
  Student
  Senior Student
  Leader
  Mentor
* Each Role includes each Sub-Role
* Phenomenarium
* Generic Enhanced Lecture (#16759)
* Documentation for each sub-role of each role with instructions for moving up
* Wills
  Someone disappears, their objects can be given by a will to a role(s) or person(s); either up or down in subroles/roles
  in the case of eDUcore, "the house burned down" and now it's not accessible to anyone
* @emergency will contact people in a particular role In Physical Life if necessary
  - there will have to be a points system involved in allowing this, to avoid abuse
  - multiple people can vote to contact/not contact
* @911 - summon help from highest people currently connected
* @witness - begin recording
* style[sheet]s -- send an out-of-band stylesheet with the text output, view can process as desired
* feature objects can be accessed by typed command, or by menu nested under the name of the feature object
* there should be a clear path at all times how the person can proceed to learn more, demonstrate more, earn (as in points/votes) more
* any quotas should only be as absolutely necessary to keep the system going
  - should be avoidable as AWS server can be upgraded quickly and easily
    - only concern would be the subsequent cost of the server
* whenever the system gets new resources, all existing quotes should be increased accordingly
* Student Information Systems data collection/reporting features
* Curriculum
  - Draw on Wikipedia
  - Draw on WikiBooks
  - Draw on other WikiMedia projects as helpful
  - Give back
  - the only problem if we rely on existing sources like these is that if that system went down, we'd lose that functionality
* EBAS features
  * Charts
* $classroom
* $gel = Generic Enhanced Lecture
* feature requests, so if User A can't do it, goes to Role A where someone to follow up is selected
* port useful shell utils such as shell itself, sed, awk, mv, sort, vi
* evaluate PowerShell for ways of doing things that we can learn from.
* Workflows/Progresses
* smart command processing
  * if command looks wrong, maybe it can be parsed with some words removed/changed? - ask for confirmation
  * "look over there" --> Did you mean "look there"?
* Workflows and Calendars
* can easily add a table to an object
  object.tables = {@object.tables, "subjects");
  object.subjects.columns = {"id","name","description"};
  object.subjects.id = {1,2,3};
  object.subjects.name = {"Al", "Betty", "Charlene"};
  object.subjects.description = {"descA", "descB", "descC"};
* can now "select name,description from subjects on object"
* views
* user-defined functions
* triggers
* as long as someone enters a room legitimately, listening is allowed by default
* if a room must be locked or listening disabled, a reason is given with the command to do it
* we're an EDUCATIONAL system
* dispute resolution process
  * mediators/arbitrators
  should go something like
    work it out 1:1
    if that didn't fix, work it out with a small group
    if that dind't fix, take to larger community
*only the <n> items with the fewest points can be removed from a list
   wizard can force it to bottom of list, then remove
* figure out how to reconcile principle-of-least-priviledge with desire to leave as much as possible readable for educational purposes
* DeleteApprover role
    A deleteApprover's priviledge may be limited by points to items with a certain low percentage of total points assigned to items in the list
    So someone in DeleteApprover10 role can delete items with less than 10% of the available points
* SeeDeleted role
  users who can see "deleted" content
* Donations
*$recycler
*$core
*$rootCore, $deCore {distance education core}, $editorCore
*$cores.myCore, $cores.yourCore
  - a "core" is any group of objects none of which has any dependency on any object not in the group
  - for testing this, and for updating cores, it would be helpful if all object references are flagged
    - that way you can quickly check whether any of them refers to a missing object
*$viEditor
*$emacsEditor
*$edEditor
*$hexEditor
*$listEditor
*$noteEditor
*$mailEditor
*$picEditor
*$vrmlEditor
*$htmlEditor
*$xmlEditor
*$regularExpression
*$soundEditor
*$codeEditor
*$sourceControl
*$helpEditor
*$outsideEmailEditor
*paging
*whispering
*inter-MOO paging
*live translation
  - one person in the room "speaks.
    -each person's view shows the speach to them in their own language
* each $_editor has a corresponding $_utils so programmers can use the editor-specific features
  - taken to extremes, this would mean only one $editor which acts appropriately depending upon which plugin you apply
  - reality is that many editors are going to have to do something a little differently that would make them difficult for another editor to adapt to
* most objects should have a .description AND a .ascii
  * this provides maximum accessibility
* some people may be visual in nature, but don't always have access to a graphical browser
* pictures can also include vector, raster, lineChart, barChart, pieChart, buttleChart, video, vrml
* by having at least ASCII art on everything, if someone only wants txt it can be delivered; if they want a picture, it can be done,, even if it 

doesn't apper to really fit right.
* list of resources
  - MOOs
  - People
  - Web

  - What is it?
  - Who can get it?
  - How will it help the system?
* list of useful MOO objects
  - Who
  - What
  - Where
  - When
  - Why
  - How
  - Must be free
  - Generic Enhanced Lecture
  - Cindy's class on Enhanced Lecture
      - gets about 1000000 points from me
  ' 
* list of free licenses
  -must allow anyone to:
    . make a copy
    . change it
    . use it
    . pick up where we left off
* can we save the World (MOO)?
  - is there educational value?
* can we save Meridian MOO
  - yes, educational benefit
* customer service
  - let's get it right
  - set expectations
  - follow through
  - follow up
* visible calendars
* visible task lists
* Documentation
* KnowledgeBase
*$helpDesk
  ?Player
  ?Builder
  ?Programmer
  ?Manager
  ?Wizard
  -every active member of a role should either be asking questions, or answering them
  -if a queue gets too bad, everyone in that role loses some helpfulness points
  -gain helpfulness points either by asking or by answering
-least priviledges
  -when signing in, if you are allowed more than one role, pick the one to sign in to
  -defaults to lowest available to you
-feature objects can convey priviledges