Product Management

Introduction

Concourse is an open source product that takes the best ideas from both SQL and NoSQL to create a database that fundamentally improves the experience that developers have writing scalable applications. That means that the same people who use Concourse should be the same people who develop it. We aim to manage the product and community in an open and meritocratic fashion. All constructive contributions are welcome. May the best ideas win.

Checkout the Roadmap to see how the product has evolved and where we plan to take it.

Design Principles

To ensure that Concourse continuously meets a high quality bar, contributions must always be vetted to ensure that they mesh with our design principles. These principles are fluid and should evolve over time, but the basic sentiment should always be to create a database system that is simple, but flexible and powerful.

Press Play in Production (P3)

Concourse should work in a production environment right out the box with no assembly required. Features should leverage pre-installed/core system resources as much as possible, and any third party dependencies should be packaged with the application. The user should never be forced to manually configure anything (e.g. edit paths, move files, etc) in order for Concourse to work. The system should be configurable where necessary, but must have reasonable defaults that are suitable for the vast majority of cases

One Stop Shops

Any given task should only require the user to look in one place. For example, all configuration parameters should go in a single file and all log files should go in a single directory. 

No XML

For the love of God never use XML.

Product Development Cycle

We appreciate the fact that members of our community are busy with day jobs, lives, etc but still want to contribute to Concourse. We want to ship new releases as quickly as possible, while also giving people enough time to ensure that their contributions are high quality. To that end, we try to ship a new functionality every 8 weeks with update releases as often as necessary.

 PurposeLogisticsObjective
Week 1Planning/Research
  • All code changes go on a feature branch
  • Choose which new features and bugs to work on
Week 2Planning/Research
  • All code changes go on a feature branch
  • Spec out all new features and have solid implementation plans
Week 3Development
  • All code changes go on develop branch
 
Week 4Development
  • All code changes go on develop branch
 
Week 5Development
  • All code changes go on develop branch
  • Ship an alpha release
Week 6Development
  • All code changes go on develop branch
  • Write manual test plans
  • Write end-to-end integration tests
  • Ship the first beta release
Week 7Testing
  • All code changes go on release branch
  • Switch from staging to maven release repo
  • Ship a release candidate
Week 8Testing/Release
  • All changes on develop branch merged into master branch before release
  • Create a support/hotfix branch after release
  • Ship GA