Branding and Preview Web Site Issues Meeting

This was a continuation of Monday's branding meeting where we started to discuss issues around the Chandler Preview Web Presence, what type of information appears at this domain and how that fits in with all the existing pieces of our wiki, blog, mailing lists etc. We also touched on some other areas of branding - positioning statements and naming.

Some of these topics will be on the agenda for the weekly Preview meeting on Monday.

Notes

Positioning statements

• Don't quite remember where we were at the last conversation.
• Pieter has a master list of options that we came up with.
• Good idea to revisit this now that we have gone through the naming exercise.
• Pieter: think about crafting position statements for particular use case persona.
• What we have currently are seeds of position statements.
• Need to get from position statement to elevator pitch.
• Mimi - do we need a tagline and a noun to describe Chandler?
  • Pieter will re-engage Caroline on this
  • Need a descriptive name about the product
  • Tagline might come up from the positioning statement.
• Next Actions:
  • Pieter to send out information for all the positioning statements we had been working on. This will help people figure out where we left off.
  • Ted was going to provide a basis for how to talk about our brand for the developer community
  • Add this to the agenda item for Monday - Pieter will come up with a set of next steps

Naming the components

• What are all the things we need to name (brainstorm)
  • Suite/solution
  • Desktop
  • Server
  • Web UI
  • Service
  • SNARF
  • Desktop platform
• Should we consider names for users vs names for developers?
• Users
  • Desktop
  • Suite
  • Web UI
  • SNARF
• Don't really need Server and Web UI on their own. They are part of SNARF.
• Desktop platform - probably don't need this - it's part of the desktop
• Things we need to name - converging on...
  • Suite/solution
  • Desktop
  • SNARF
  • Service
• Next actions:
  • Think about these names and come with some lists to consider on Monday
  • Pieter will send out some examples of things that describe a solution

Integration of exisiting componens with the new domain

Jared came prepared with a list of logistical/technical questions - decisions that impact his work that brought up a more fundamental issue around how we are going to integrate all the existing pieces ie: wiki, mailing lists etc in with the new domain for the product. We are going to take this discussion to the PR list for input.

• Jared's list of questions
  • Do we move the wiki to the new domain while maintaining backwards URL compatibility?
  • Do we move the blog to the new domain?
  • Do we move the mailing lists?
  • Do we move the download site?
  • Do we move development support - svn, bugzilla, view cvs (left nav of the wiki)
  • Where do staff bios go? osafoundation.org or chandlerproject.org?
  • Do we have a separate service status site? chandlerservice.info?
  • Do we have a separate service status blog?
  • Do we use a new blog back-end? Some concerns raised?
  • Do we provide BitTorrent^? or other non-http downloads
  • What dynamic content do we use. Do we have mirror sites for downloads?
  • Do we move the people site?
  • Things we are not moving - pylucene, m2 crypto
  • Do we use sub sites or do we use a path?
  • Pieter: How do we handle language - sub sites vs foreign domains?

• We examined several high-level proposals
  • 1. Combining organization site and blog
  • 2. Keep osafoundation.org small (just about non-profit). The blog would go within the project.
  • 3. All Product related stuff to new domain, project/dev stuff tied to non-profit.

• Observations
  • Some agreement that there were too many presences and we should think about consolidating those
  • Requirement: Brand conceptually unifying to the public domain
  • We have both end user content and developer stuff
  • Most of the end-user content hasn't been developer - what we have now is more project oriented
  • Mimi feels that what we are working on (chandlerproject.org) from an end-user perspective is more project oriented
  • Ted: leave wiki where it is. Current content not suitable for end-user. Leave the mailing lists and start with new content. Leave the blog that we have alone and start a new end-user facing blog.
  • Mimi - worries that we might be segregating users vs developers.
  • Concerns over fragmented presence - to many sites
  • Why can't we just have a users channel in the blog we have? Can you subscribe to a particular channel in the blog - No.
  • Blog we have should move to the chandler project domain - general audience blog.
  • Moving the existing blog is pending some technical concerns - Jared will follow-up.
  • Pieter: OSAF - just become the foundations website - not about the Chandler project.
  • Ted: Ok to just have stuff about non-profit.
  • Vision stuff - may have to go in both places
  • People - belongs in the foundation site - about employees of the foundation.
  • We should have a list of contributors on the product site as well - even if it's repeated on the www.osafoundation.org site
  • When you land on www.osafoundation.org - it should be obvious how to get to the Chandler project pages.
  • News - general audience news goes to the blog. Don't need a news channel.
  • Where do job postings go?
  • List of contributors on the project site seems like it's in tension with wanted to link all the developer related info from the foundation.
  • Katie: propose not a newschannel@osafoundation.org
  • Developer blog/mailing lists/wiki - not move for practical reasons.
  • Chandlerproject.org - just use this for everything? We don't all agree on this.
• Things we agreed on/decisions
  • We need to have a general audience/user blog and it should be part of the chandlerproject.org domain (pending technical considerations). We would move our current blog and then potentially create a new one for developers.
  • We will not move the mailing lists or the wiki.
  • We will not create a news channel

-- SheilaMooney - 01 Feb 2007