Raindrop/Milestone/Maple

Maple is the first post-reveal milestone. End date is Nov 10, 2009. Trying to pick Tuesdays since they correspond with a weekly call.

Current list of items being considered is below. We should focus on one to two bigger items and some smaller clean-up items.

View Maple Trac tickets

Big

• Inflow Design #3: Bryan and Andy have worked out the start of iteration 3, which is a combination of inflow #1 and inflowgrid. Basically, use inflow #1 for personal conversations, but use grid layout to the right of it to show grouped conversations. Specific tasks:
  • Bryan and Andy posted to design blog about the design. They continue to iterate.
  • James tagged the tree as 0.1, updated wiki page to point to the tag if people want to see the code that was in the reveal, and mentioned different things are happening on the trunk.
  • James to clean up the inflow and client/lib to be optimized for iteration 3. Inflow #1 and inflowgrid will be deleted, and the widgets will be cleaned up to fit iteration 3's needs.

• Define set of message combinations we can see (direct message turned to a group message, group message forwarded to an individual, different types of notifications, newsletters vs. listserv mail). Then seed Jean's account with that info.
  • Bryan to start wiki page listing out the combinations.
  • TBD populates Jean's accounts with the combinations.

• Web API work. Start working on better web APIs. Take the opportunity with Iteration #3 to clean up the old JS code used in the client. The JS code is already split into a higher level app API and a lower level, more couch-based API, make the distinction clear in the JS code and use it to inform a server-side API.
  • James to clean up JS code, make sure the low level and high level ones are distinct. Discuss with Mark.
  • Mark to build up up some primitives to have some Python code run in an external so we can try porting the JS APIs to run on the server. Basic services needed: wrappers for doing megaview calls, fetching documents, merging results together.
• Mark and James to split up coding tasks on the Python server stuff once the basic API is designed.

• Start work on metrics collection: this is two parts, an extension asking permission to collect metrics, and then logging the metrics somewhere. Initial pass, maybe just log the metrics in a separate couchdb database and consider using replication back to a common server?
  • Andy/Bryan to consider design and language of the extension asking for permission, model it on Test Pilot.
  • TBD to do metrics extension.
  • Mark to do any setup for a metrics DB?

Community Involvement Opportunities

These are things that can benefit from community involvement. You can help out with the following!

• Explore some JavaScript server side options. At this point we want to try to avoid an option that requires Java, but just to cut down on our code dependencies. It may be considered later if a suitable solution is not found. Two options stand out:
  • Explore couchJS. Can it be used for our purposes? Need network and probably restricted file access to load some JS library code. Mark has done a pass on this, and we need fixes in CouchDB for curl support in couchjs.
  • Explore Pydermonkey. Would be nice particularly if it has access to Python libraries, but at a minimum need network and restricted file access.

• Security: Please see the Security wiki page for more information. Anything we can do to start securing user data better and securing the couch is appreciated.

Small

• Trac tickets that are post-reveal. Move anything you want to do to the Maple milestone.