Getting Started
This section is an overview of how we approach working together It is not a legal agreement to be used as a reference in lieu of a contract.
General Approach
Terminology
When developing for We The Curious there are many considerations, particularly for complex builds and so terminology can become ambiguous. This is for clarification. We try to use these terms consistently, but sometimes we don't
Exhibition Space
The entire publicly accessible interior of We The Curious
Exhibition
A Exhibition is an area containing one or more exhibits
Constellation
A sub grouping of exhibits within an exhibition space (Currently specific to project what if)
Exhibit
A single experience 'package' including the hardware, housing, setwork and software
Experience
An exhibit with additional considerations of how it appears in the space and how a user approaches the exhibit before interaction.
App
The application running the exhibit. An app will generally belong to one exhibit, but may belong to multiple.
Service
A service is a single piece of software. Generally an App will have one service but it is possible for an App to have multiple services for example when there are two different interfaces controlling different parts of the exhibit.
Instance
Exact copies of an exhibit, app or service running to provide an identical experience at multiple points
Version Control
Development must be version controlled in git. We will provide a link to a remote repository which should be used for all push commands
We use git flow pattern for branch naming in git. We prefer that you use this pattern but it is not a requirement, except for master and develop branches as these are used for our CI process.
Continuous Integration
To provide continuous feedback to the content team at We the Curious. We are setting up a CI process for delivering apps to exhibits in prototyping or on the floor.
Our default deployment target for interfaces is web apps running on brightsign players. If you are using this for your development we have a preset CI process using the bitbucket deployments feature. When you push to master or develop bitbucket does some setup and then copies the build to S3. The brightsign players periodically check the S3 buckets for updated objects and download them for use. Code pushed to the master branch will be pushed directly to the exhibition floor while code pushed to develop will go to the prototype rooms.
If you are not using our default deployment target then how we manage and review updates will need to be negotiated on a per project basis
Licensing
This section is an overview of how we approach licensing. It is not a legal agreement to be as as reference in lieu of a contract.
Code that is developed by you for us to our spec is owned by us unless there has been a contract stating otherwise. We like to work with an assumption that the code is to be released open source. We generally will decide to release open source unless there a reason not to - usually security or third party licensing.
We are currently looking for the default license we wish to use for open source.
The license you agree with us only covers the code you have developed for us under the contract. It does not extend to packages developed by you or third parties.If you intend to use packages that are proprietary you must provide documentation of what those packages are, what their function is in you software.
'Code you have developed for us' generally will be defined as code committed to the repo. If you have code that you don't want to be caught by the license please require it as a dependency.
Documentation
We do expect documentation to be provided as part of the development process. The should be supplied as a readme.md in the git repo. You must detail. The documentation should be written in such a way to be understood by a competent developer who has no previous experience of the language or environment used.
Authors of the software
The intent of the software
A step by step install process, including environment set up
License used for the software in the repo
Details of packages used and license information
Screen shots of the main screens
Examples
Our current ticketing site is the first application to be built with the SDK. You can use it here