Labs/Site 2.0/Site requirements, goals, and general principles

From MozillaWiki
< Labs‎ | Site 2.0
Jump to: navigation, search

Principles

These are about how we'll work on this project specifically.

  • Ensure that we develop the site in the same way as all of our projects, in the open and with an iterative development process to get the widest possible review and feedback.
  • Use existing tools or software as much as possible - avoid extensive development.
  • No monoliths - modular system so we can experiment with different tools for different things.
  • No silos - information and data must flow both in and out of the system unrestricted.
  • Fast, iterative experimentation - keep what works, throw away what doesn’t, iterate on what's promising.
  • Multistage development and launch - this will not be an all-at-once rollout.
  • Balance form and function - cannot take a year to build.
  • The perfect is the enemy of the good - 80/20 rule and tweak/customize as necessary over time.
  • Everything should encourage organic growth and engagement of the labs community as much as possible.
  •  ???

Goals

  • Engage and grow an ever larger Labs community, ensuring accessibility by less technical contributors (e.g. non-engineers)
  • Project status and activity must be clear, obvious, and easy to find
  • Must be easy to do site updates (web UI/wysiwyg, not SVN)
  • Automated content updating as much as possible (web feeds, etc)
  • As low barrier to participation as possible

Requirements

  • Must scale up to 1000s of projects and 100000s of participants (although in 2009, we're aiming at 100s and 10000s)
  • No sign-on required for low-level interaction, single sign-on for anything else
  • Open source, open web, open standards all the way down (for stuff we deploy - existing third-party services that we do not host don't count here -- folks are welcome to host videos on vimeo etc.)
  • Must provide good/excellent tools for discussion - threaded, web feeds, etc. Existing Vanilla system is insufficient. (Looking at phpbb.)
  • All tools should have web feeds and/or APIs - must be able to get at the data so we can mash it up and do fun stuff with it later.
  • Must provide a polished user-facing side as well as the more chaotic developer/contributor side.
  •  ???