Skip to content
This repository has been archived by the owner on Feb 26, 2020. It is now read-only.

Planning: Features

Jump to bottom
rrocchio edited this page Nov 7, 2014 · 19 revisions

Proposed Components

  • People
    • Bio
    • Skills
    • Contact information
    • Campus
    • Projects created or involved with
    • Announcements / events a person has made
    • Ideas created / voted upon
    • Projects involved with
  • Ideas
    • Title, description, attachments
    • Value proposition
    • Voting - or Likes
    • Dependencies
    • Comments
    • Status (proposed, seeking support, started, etc. - with project link once started)
    • Type (open source or UC only)
    • Search
    • Related / merged ideas
  • Projects
    • Details about the project
    • "Likes" for the project
    • Define "QUESTS" and then participants "ACCEPT QUESTS" instead of "BOUNTIES"
    • Accepting a "Quest" is Commitment to a deliverable or hours over the next X months
    • Dates associated and or timeline for a project
    • Links off / integrations with project tools like GitHub
    • References back to ideas (if any were the catalyst for the project)
  • Social Space
    • Announcements
    • Events calendar
    • Chat rooms / forums (or what?)
    • Private messages
    • Badges or other ways of designating collaboration accomplishments
    • Place for sharing resources, links, docs, articles, etc.

Things You Like

Look at the existing Tech Idea Generation Sites and post things you like about them.

  • Lots of positivity about the filtering that Assembly provides
  • I like the idea of the "bounties" - but lets call them "QUEST" and use language like
    • "I ACCEPT THIS QUEST"
    • Which goes with the "Gamification" TONE we want to "Socialize"
    • Also, how about thinking of "LEVELS" when people do X number of "Quests" they get prizes
  • I like the categories of "Bounties" on Assembly: FRONTEND, BACKEND, DESIGN, MARKETING, WRITING, MOBILE.... However, I think we might change them to: USER STORYS, USER INTERFACE, DATA & ARCHITECTURE, DESIGN, MARKETING, WRITING, TEST DRIVE

Principles

Log in as easily as possible

Allow login via Shibboleth or any common OAuth provider

Automatically create accounts with as much info as possible from the provider in question

Don't re-invent where not required

Project workspaces shouldn't try to be another GitHub - rather they should link to it, Bitbucket and/or anywhere else that project resources reside. In a way, it should be more like what RubyGems or Chef Supermarket does.

There are tons of communication platforms already out there. We need to decide if we want forums, chat rooms and/or other things like that, but ultimately we should probably just bridge them with our app via SSO (and other integration points as needed) rather than programming any of these ourselves.

Our "secret sauce" (albeit open source and thus not really secret) will be the workflow around ideas. That's the bit that we'll almost certainly be inventing from the ground up.

Clone this wiki locally