Mark, Rob, Whit, Alec and Jackie met by conference call on 12.12.2005

Notes

• Strategy is to 1) put up something functional 2) Get people to use it 3) Listen to what those people want

• CONCERN: if have no built in audience to "design for", who will we attract if all we can do is tout our lack of features?

• We do have a built in audience which we gather using our content/editorial control and just by sheparding who shows up.
• ex. if a bunch of people interested in tutoring show up, then more people with that same interest will follow, as opposed to drawing a lot of people interested in satanic death cults, who would find all that talk of children being our future (*which doesn't exist anyway) super dull.
• For others, like the satanic death cults, the openplans software (to be named) will be available for distribution, so they can host their own instance and plot their upcoming events, rituals, deaths, etc.
• i.e. Community is the living thing we create more than the technology
  
• What are we trying to do, anyway
• We are trying to is put together a place for people to go and work and organize as they try to get something done in the real world
• Features:
• The notable thing about this conversation is that we returned to a concensus that we do want to add additional features over time, as our user base grows and has additional needs.
• Some of these additional possible features include blogs, forums, indexing and tagging, event planning, assigning tasks to users, geographic functionality
• At some point it may make sense to have one piece of software that can handle different domains (new.transalt.org for TA stuff
• Rob points out that a custom build for a group or org could help the project become more self sustaining in the long long term
• While we are all excited about radical simplicity as a guiding philosophy, there are diminishing returns when making things too simple in a way that 1) makes less sense and 2) forces us to solve problems that haven't been solved yet
• Mark has been sold on containers over just pages
• Containers have a group of elements that have the same security policy
• There is no fundamental difference in the container that is being used as a project, a person, or an article/media
• EXCEPT that a person has a defaul/non-configurable security policy that allows only him/her to edit the content in his/her personal area
  
• We want to have a concept of teams that fit the following prerequisites:
• People can associate themselves as a team
• Teams or a person can be associated with a piece of content
• Multiple teams can be associated with a given piece of content
• Multiple pieces of content can be associated with a given team
• Content association and the updating of this relationship is very easy
• Lifecycle example:
• We are organizing a PROJECT with a TEAM of PEOPLE who work to create a VIDEO which when it is complete is found tagged as MEDIA
  
• NEXT STEP: Rob will expose more of team management
• This can be on the same tab off the project homepage as the security interface (perhaps? does that still make sense if teams are separate from projects?)
• In order to have a more public launch, we must have:
• Security interface and policies
• Team management interface and the relationship of this to security and to content
• Slightly better navigation on the Projects page (the list of current projects)
• People stuff (personal space exposed)
• Other UI clean up, design-related stuff, and making it smooth and pretty