From Nasatweetup

See also: Mission Data | Mission Data - Sources | Mission Data - Forums

See also: Whuffie

---

TO DO: This page needs to be cleaned up. It's currently just a dump of the original Google Doc

Feel free to edit and add your thoughts in line or Insert->Comment. Its all about crowdsourcing afterall!!

Blog post that started it all: [1]

Contents 1 Project Scope 2 Discussion Spaces 2.1 IRC 3 Requirements 3.1 BASICS 3.2 NAVIGATION and DATA 3.3 USERS and SPACEPOINTS 4 Alternate Karma Implementation 5 Implementation 5.1 Schema 6 See also: Mission Data - Sources

Project Scope

The idea is to first implement a very simple karma based system, like Slashdot has, but perhaps with numbers instead of just qualitative terms. See this slashdot link here (read the first 5 sections) and here. This will essentially be critical in order to provide moderators with the data they need in order to quickly assess whether a addition/modification/deletion can be trusted or not.

Then second of all, we could implement either a mission event database or just simply a mission details database, which would have details of the communication system, power system, science/technology payload, etc.

TO DO:

• Select a project name (MissionClock would be confusing)
  • Requirement: domain name available
  • missiondata.org
  • spaceclock.org
  • spacepts.com (missions.spacepts.com)
• Set up a development space
  • Unless there are objections, @bonkoif will set up AWS services to start developing the data schema and interface (Will do on 6/11, pending comments)

Discussion Spaces

IRC

We have an Internet Relay Chat channel set up on Freenode in channel #spacepoints. You will need an IRC client such as:

• Colloquy (Mac, iPhone, iPad)
• mIRC (Windows)
• ChatZilla (Firefox add-on)

The URL for the chat room is irc://irc.freenode.net/%23spacepoints

OR

You can use the web client here: http://webchat.freenode.net/?channels=spacepoints&uio=d4

Requirements

BASICS

1. This site should run on a standard web server
2. This site should be designed more like an Apple product than a Microsoft product, in that it has incredibly simply & minimalistic user interface (UI) and experience (UX)
3. This site should have a industry standard authentication mechanism (i.e. OAuth), such that folks can log in using their Facebook, Twitter, Google accounts
4. This site should not aim too high, but provide very simple functionality, like that of the iOS app, Mission Clock

NAVIGATION and DATA

1. This site should allow for a user to browse nearly all missions from a top level page, and then drill down to view mission details
   1. This top level page should be in the form of a table or a very short block for each mission
   2. From the main page, the user should see: the title of the mission, the launch site, a live countdown/up clock (i.e. using Javascript), the title of the next upcoming event, and the number of events created for that mission
   3. When a user clicks on a individual mission, they should be able to see: window open, window duration, window close, launch vehicle, launch site, overview text, and a listing of all events (which have details of: event title, time start, time end, all in DOY, T-, L-, and a realtime coundown clock)
2. Every data field as listed above should have an accompanying history, URL, and comment text. This is very similar to what a wiki provides, in that every change is kept, and has a comment, so this makes it very easy for changes to be reviewed. In addition, each change should have a referencing URL which provides the citation which will allow for the new data update to be verified.

USERS and SPACEPOINTS

1. Once a user logs in, they should be able to see added features of being able to add/modify/remove missions&events
2. This functionality should be granular based on how many SPACEPOINTS the user has
3. If a user is new, they can make changes, but those changes will not show up unless they are moderated first
4. Users should be able to be set up in the following roles: standard user, moderator, administrator
   1. Standard users will have the ability to recommend changes, but none of these users’ changes will show up until accepted by a moderator
   2. Moderators have the ability to see all the data field additions/modifications/removals which have been recommended and can with one click approve or deny. All moderators can see these actions which all other moderators have made. Moderators can approve their own additions/modifications/removals.
   3. Administrators have the ability to do all that moderators can, plus they can edit all the history/URLs/comments on all data fields. Administrators can also change user rights and ban users.
5. Every user should have a simple profile page which lists their current ranking, SPACEPOINTS, and history of activity. Only on this page can other users see the unapproved additions/modifications/removals which other users have made. Also on this profile page, each user can customize profile text (up to 160 characters) and one link to their web presence (twitter, blog, etc.)
6. Every time a user gets a addition/modification/removal approved, they should get X [TBD] more SPACEPOINTS.
7. Every time a user gets a addition/modification/removal denied, they should get X [TBD] less SPACEPOINTS.
8. Other users can give each other “thumbs up” which will give the receiving user X [TBD] more SPACEPOINTS.
9. Administrators receive SPACEPOINTS for moderating additions/modifications/removals.

Alternate Karma Implementation

1. Dual interfaces to “unapproved” modifications: User can select a page that shows them all in one place, or they will see an indicator when browsing through missions and events
2. Any user can up/down vote a particular piece of data once and only once
   1. Posting user does not get points for up/down vote of their item, it just makes it more or less visible to the mods? Or maybe a small amount?
3. Piece of data starts with a certain number of automatic upvotes based on the posting user’s karma
4. Any mod can approve/reject a particular piece of data
5. Users can only edit data of someone with less karma than them (hmmm...)
   1. What happens with other users who edit the data before the mod gets it?
   2. Maybe split the points based on how much was changed by each user?
      1. e.g. calc a “% change” between the original entry and the edit
6. If the mod has to edit the entry before approval, the entering user gets fewer points than if the mod approved it without edit
   1. Make editing objects be copy on write (i.e. a new object gets created) so we can maintain the original for tracking
7. Connection to SPACEPOINTS
   1. Maybe you can use points to buy karma?
   2. People with lots of karma should get SPACEPOINTS for that

Possible Karma Chart:

Action	Points	Notes
Add new entry	+2
Up/Down vote entry	+0.01	it’s a free action to vote on an item, but you get credit for doing it
Entry is approved w/o edit	+5
Entry is rejected	-2	cancel out add - should there be a penalty too?
Entry is approved w/edit	+2

Additional thoughts/future implementations:

• Use Facebook connect in order to have activity on SPACEPOINTS cross post to users’ wall?
• How visible to make points? Should we take the course of Foursquare, which actually hides whats required to get certain badges? Maybe only update a user’s SPACEPOINTS every 10 they get? That way there is some mystery to it?
• Present multiple calendar interfaces for users. They should be able to get an iCal feed of all launches (or a subset of launches based on criteria like site). They could also get an iCal feed of all the events for a given mission.
• The mission clock, with holds, is a little tricky. How did Rick end up implementing this in MissionClock?

Implementation

• In order to set this up, we’re going to need a domain name, web server and a database
• Do we have ability to set up a custom domain and servers already?
• May be easier to just use Amazon AWS because we can scale it quickly when this takes off, while using fewer resources now while we’re developing
• We can use the AWS free tier to get started, and worry about paying for it later

Schema

(all models have created/updated/deleted dates. deleted date != NULL means it’s deleted)

• Edit
  • belongs to new (Object)
  • belongs to original (Object)
  • belongs to User
  • property: percent change (from original)
• User
  • has many Edits
  • has many Transactions
  • has many Votes
  • has many Objects
  • belongs to Role
  • property: current karma
  • property: time zone
• Role
  • has many Users
  • property: name (i.e. View Only, Normal User, Mod, Admin)
  • property: description
• (Karma) Transaction
  • belongs to User
  • property: amount
  • property: cause (use this for what action caused the transaction)
• Vote
  • belongs to User
  • belongs to Object
  • property: up or down
• Object
  • has and belongs to many Objects
  • has many versions (Objects)
  • has many Edits
  • has many Votes
  • belongs to creator (User)
  • belongs to moderator (User) NOTE - approved if linked
  • property: name
  • property: description
  • property: starting votes
• Site (kind of Object)
  • has many Missions
  • property: location
• Vehicle (kind of Object)
  • has many Missions
• Mission (kind of Object)
  • belongs to Site
  • belongs to Vehicle
  • property: window open
  • property: window close
  • property: mission clock (that holds at the proper points)
• Event (kind of Object)
  • property: time of event
  • property: type (launch, hold, landing, what else?)
• Image (kind of Object)
  • property: URL
• URL (kind of Object)
  • property: URL
• Wiki Page (kind of Object)
  • property: URL

See also: Mission Data - Sources