An overview of the priorities for OpenPlans and OpenCore development from October 2006 until April 2007.

Status: In Process  (not to be considered authoritative)

TOPP's priorities for the OpenPlans project can be considered within the context of a number of "guiding principles".  This document will attempt to describe some of these principles, providing for each some user stories and some means by which these user stories can be realized in the features and services that we will provide.

"Action at a distance" : openplans.org as a service provider

Overview

There is general consensus that we want to get away from expecting openplans.org to be thought of as a "destination" on the web.  Rather, we want openplans.org to be able to provide services to individuals and organizations within the context of those entities' already existing web presence.

User Stories

1. "The Rant."  Some user is ranting about some issue that pisses her off, in her blog or in some other .  She decides she doesn't just want to rant, she wants to Do Something(tm).  And she wants other people to get involved.  She wants an OpenPlans project!  But she's not going to want to leave the context of her blog site to make this happen; too much effort, we've lost her already.  We want her to be able to create a project and link to it from her blog post without ever having to leave her blog interface.
2. "The NGO."  Some existing non-profit organization wants to use our services, such as our wikis and mailing lists, but they already have an established web site, with a clearly defined look-n-feel, and a recognizable domain name that they want to keep using.  They want to embed services that we provide into their site, not send someone to resources that exist on ours.

Solutions

1. Making Listen a service.  This could allow simple setup of a list, either through specially-coded gateways through codebases like Drupal (where Drupal does all the communication with our Listen installation, so it's potentially as simple as entering in the list name and that's it).  Another use case Listen might be able to handle that is fairly novel is extremely light-weight lists; e.g., set up a working group for a specific event (e.g., a fundraiser).  Usually list setup is too heavy for short-lived lists like this.
2. Create "stub" projects, which are projects that are primarily located someplace else.  A stub project could potentially be created just by giving the real homepage for the project, and you could glean the title and other metadata from that page.  If we can encourage projects to embed hCard or other microformats, we could get a lot of metadata from a project page.
3. Ability for users of openplans to have own URL, to not have to be under openplans.  This is probably very simliar to #2, may be the same, but perhaps may be just lower hanging fruit - we just need to have an openplans project show up under another URL.
   

Open Identification

OverView

OpenPlans doesn't want to become Yet Another Account To Manage.  We'd like to support allowing people to authenticate against existing services, such as gmail, and also to allow people to authenticate off of some idea of a central internet identity, possibly even being an identity provider in some central identity protocol for folks who create accounts with us.  The OpenID initiative seems to be gaining momentum, and there is already a PAS plugin and Plone integration for us to use, seems like a good place to start.

User Stories

1. A user is participating in a community like Nabuur, and wants to use a tool from Open Plans in a project there.  They don't want to create another login, and would like a fairly seemless experience.
   

Solutions

1. Nabuur implements an Open ID server, or at least consumes Open ID logins by default.  The user points us to their Nabuur user homepage, which contains the Open ID information; the rest of the login is automatic (if they've already logged into Nabuur), or uses their Nabuur login information otherwise.  Nuisance -- there's still a lot of clicks involved to login.  One to give their Nabuur user homepage (we can later keep it in a cookie, but then one to confirm their homepage).  Then they go to Nabuur, and may have to login, or at least typically confirm that they want to allow this login (potentially we can get Nabuur to trust us, and not require confirmation when the user is already logged in).  But it's better, and can maybe be optimized when communicating among cooperative/complementary services.

Links

1. Google authentication page

Improve what we have

OverView

While chatting w/ Cholmes, Whit, Scott, and myself (Rob), Mark expressed quite clearly that he thought it more important to improve the usability and usefulness of the features that we currently have than to add new features.

User Stories

Solutions

1. Investigate xinha as an alternative to kupu for use as our WYSIWYG editor.  Generally there's some better content features we want: spell check, better right-clicking (what are the others?)
   
2. WebDAV is currently a bit wonky, since each page is a collection but also contains the primary (textual) content.  Maybe Enthought's Plone DAV products can handle this (Windows' Web Folders work really poorly, even if we weren't breaking WebDAV assumptions).
3. Better user homepages, prompting users to upload their photos, maybe link to their friends, ect.
4. Small layout stuff.  There's a lot of things that just haven't gotten a fine toothed comb going over them.  We just need a couple people to take the time and make all the small litlle improvements.
5. Better URL's.  Would be nice to be able to say http:/myproject.openplans.org or perhaps even just www.openplans.org/p/myproject (on a suggestion Jackie found).