You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Each commit message consists of a mandatory header, an optional body and an optional footer. The header has a special
format that includes a type, a scope and a subject (full explanation):
No worries if this format is new to you, try using commitizen to streamline the commit messaging. This project checks message format on commit using validate-commit-msg, so if your commit fails, please address the issues in the commit message and try committing again.
Patch Release
fix(pencil): stop graphite breaking when too much pressure applied
Minor Feature Release
feat(pencil): add 'graphiteWidth' option
Major Breaking Release
perf(pencil): remove graphiteWidth option
BREAKING CHANGE: The graphiteWidth option has been removed. The default graphite width of 10mm is always used for performance reason.
Bug triage
This section explains how bug triaging is done for brigadehub. Help beginners by including examples to good bug reports and providing them questions they should look to answer.
Look at existing bugs and help us understand if
** The bug is reproducible? Is it reproducible in other environments (browsers)? What are the steps to reproduce?
You can close fixed bugs by testing old tickets to see if they are
happening
You can remove duplicate bug reports
Documentation
Code needs explanation, and sometimes those who know the code will have trouble explaining it to someone just getting into it.
Most of our immediate conversations happen here. For more pressing matters, we try to set up Google Hangouts, and each week at SF Hack night, we set up a video Hangout for standup. Please let us know if you would like to join that.
Otherwise, feel free to open a discussion via Github Issues, and we can get back to you soon! Here are some other things you can do to help out:
Create an example of the project in real world by building something or
showing what others have built.
Write about other people’s projects based on this project. Show how
it’s used in daily life. Take screenshots and make videos!
Your first bugfix
This section should help a person get started with their very first bug fix and thinking through the problem.
If you have further questions, contact:
This contributing file template is from contribute.md.
Before starting
Have the application installed and running locally on your machine
Have Zenhub installed in your chrome browser so you can see both the Epics and the Boards we are using
Have looked through and understand the Brigadehub Roadmap and the feature list for the current release push.
This application has a lot of moving parts, and we're working hard to make sure those parts are fitting together nicely. If you have any questions, please don't hesitate to ask.
The easiest way to get started is to clone the repo:
# Get the latest snapshot
git clone https://github.com/sfbrigade/brigadehub.git
# Change directorycd brigadehub
# Install NPM dependencies
npm install
# If needed, start mongodb in a separate tab
mongod
npm start
# or if starting for local development:
npm run develop
Obtaining API Keys
To use any of the included APIs or OAuth authentication methods, you will need
to obtain appropriate credentials: Client ID, Client Secret, API Key, or
Username & Password. You will need to go through each provider to generate new
credentials.
I have included dummy keys and passwords for Github to get you up and running
even faster. But don't forget to update them with your credentials when you
are ready to deploy an app.
- Go to [Account Settings](https://github.com/settings/profile)
- Select **Applications** from the sidebar
- Then inside **Developer applications** click on **Register new application**
- Enter *Application Name* and *Homepage URL*
- For *Authorization Callback URL*: http://localhost:3000/auth/github/callback
- Click **Register application**
- Now copy and paste *Client ID* and *Client Secret* keys into `.env` file
Project Structure
Name
Description
config/default-brigade.js
Default brigade profile.
config/passport.js
Passport Local and OAuth strategies, plus login middleware.
controllers/about.js
Controller for about form.
controllers/blog.js
Controller for editing/creating/displaying blog posts.
controllers/brigade.js
Controller for brigade login and page management.
controllers/events.js
Controller for events calendar and individual event pages.
controllers/home.js
Controller for home page (index).
controllers/projects.js
Controller for /projects route and all projects examples.
controllers/user.js
Controller for user account management.
models/Brigade.js
Mongoose schema and model for Brigade.
models/Content.js
Mongoose schema and model for site content.
models/Events.js
Mongoose schema and model for Events.
models/Posts.js
Mongoose schema and model for blog Posts.
models/User.js
Mongoose schema and model for User.
node_modules/
Storage for all node modules.
test/
Tests for routes and models.
themes/atl/public/
Static assets (fonts, css, js, img).
themes/atl/public/js/main.js
Place your client-side JavaScript here.
themes/atl/public/css/main.css
Main stylesheet for your app.
themes/atl/public/css/themes/default.scss
Some Bootstrap overrides to make it look prettier.
themes/atl/views/about/
Templates for about page.
themes/atl/views/account/
Templates for login, password reset, signup, profile.
Your API keys, tokens, passwords and database URI.
app.js
Main application file.
setup.js
Tool for removing authentication providers and other things.
Note: There is no preference how you name or structure your views.
You could place all your templates in a top-level views directory without
having a nested folder structure, if that makes things easier for you.
Just don't forget to update extends ../layout and corresponding
res.render() paths in controllers.
List of Packages
Package
Description
async
Utility library that provides asynchronous control flow.
bcrypt-nodejs
Library for hashing and salting user passwords.
bitgo
Multi-sig Bitcoin wallet API.
cheerio
Scrape web pages using jQuery-style syntax.
clockwork
Clockwork SMS API library.
connect-mongo
MongoDB session store for Express.
dotenv
Loads environment variables from .env file.
express
Node.js web framework.
body-parser
Express 4 middleware.
cookie-parser
Express 4 middleware.
express-session
Express 4 middleware.
morgan
Express 4 middleware.
compression
Express 4 middleware.
errorhandler
Express 4 middleware.
method-override
Express 4 middleware.
serve-favicon
Express 4 middleware offering favicon serving and caching.
express-flash
Provides flash messages for Express.
express-validator
Easy form validation for Express.
fbgraph
Facebook Graph API library.
github-api
GitHub API library.
jade
Template engine for Express.
lastfm
Last.fm API library.
instagram-node
Instagram API library.
lob
Lob API library
lusca
CSRF middleware.
mongoose
MongoDB ODM.
node-foursquare
Foursquare API library.
node-linkedin
LinkedIn API library.
node-sass-middleware
Sass middleware compiler.
nodemailer
Node.js library for sending emails.
passport
Simple and elegant authentication library for node.js
passport-facebook
Sign-in with Facebook plugin.
passport-github
Sign-in with GitHub plugin.
passport-google-oauth
Sign-in with Google plugin.
passport-twitter
Sign-in with Twitter plugin.
passport-instagram
Sign-in with Instagram plugin.
passport-local
Sign-in with Username and Password plugin.
passport-linkedin-oauth2
Sign-in with LinkedIn plugin.
passport-oauth
Allows you to set up your own OAuth 1.0a and OAuth 2.0 strategies.
paypal-rest-sdk
PayPal APIs library.
request
Simplified HTTP request library.
stripe
Offical Stripe API library.
tumblr.js
Tumblr API library.
twilio
Twilio API library.
twit
Twitter API library.
lodash
Handy JavaScript utlities library.
validator
Used in conjunction with express-validator in controllers/api.js.
mocha
Test framework.
chai
BDD/TDD assertion library.
supertest
HTTP assertion library.
multiline
Multi-line strings for the generator.
blessed
Interactive command line interface for the generator.
yui
Used by the Yahoo API example.
Useful Tools and Resources
JavaScripting - The Database of JavaScript Libraries
JS Recipes - JavaScript tutorials for backend and frontend development.
When installing an NPM package, add a --save flag, and it will be automatically
added to package.json as well. For example, npm install --save moment.
Use async.parallel() when you need to run multiple
asynchronous tasks, and then render a page, but only when all tasks are completed. For example, you might
want to scrape 3 different websites for some data and render the results in a template
after all 3 websites have been scraped.
Need to find a specific object inside an Array? Use _.find
function from Lodash. For example, this is how you would retrieve a
Twitter token from database: var token = _.find(req.user.tokens, { kind: 'twitter' });,
where 1st parameter is an array, and a 2nd parameter is an object to search for.
FAQ
I am getting MongoDB Connection Error, how do I fix it?
That's a custom error message defined in app.js to indicate that there was a
problem connecting to MongoDB:
mongoose.connection.on('error',function(){console.error('MongoDB Connection Error. Please make sure MongoDB is running.');});
You need to have a MongoDB server running before launching app.js. You can
download MongoDB here, or install it via a package manager.
Windows users, read Install MongoDB on Windows.
Tip: If you are always connected to the internet, you could just use
MongoLab or Compose instead
of downloading and installing MongoDB locally. You will only need to update database credentials
in .env file.
I get an error when I deploy my app, why?
Chances are you haven't changed the Database URI in .env. If MONGODB/MONGOLAB_URI is
set to localhost, it will only work on your machine as long as MongoDB is
running. When you deploy to Heroku, OpenShift or some other provider, you will not have MongoDB
running on localhost. You need to create an account with MongoLab
or Compose, then create a free tier database.
See Deployment for more information on how to setup an account
and a new database step-by-step with MongoLab.
Why Jade instead of Handlebars?
When I first started this project I didn't have any experience with Handlebars. Since then I have worked on Ember.js apps and got myself familiar with the Handlebars syntax. While it is true Handlebars is easier, because it looks like good old HTML, I have no regrets picking Jade over Handlebars. First off, it's the default template engine in Express, so someone who has built Express apps in the past already knows it. Secondly, I find extends and block to be indispensable, which as far as I know, Handlebars does not have out of the box. And lastly, subjectively speaking, Jade looks much cleaner and shorter than Handlebars, or any non-HAML style for that matter.
Why do you have all routes defined in app.js?
For the sake of simplicity. While there might be a better approach,
such as passing app context to each controller as outlined in this
blog,
I find such style to be confusing for beginners.
It took me a long time to grasp the concept of exports and module.exports,
let alone having a global app reference in other files.
That to me is a backward thinking.
The app.js is the "heart of the app", it should be the one referencing
models, routes, controllers, etc.
When working solo on small projects I actually prefer to have everything inside app.js as is the case with this
REST API server.
I don't need a sticky footer, can I delete it?
Absolutely. But unlike a regular footer there is a bit more work involved.
First, delete #wrap and #footer ID selectors and html, body { height: 100%; }
from main.less. Next, delete #wrap and #footer lines from layout.jade
(By the way, if no element is specified before class or id, Jade assumes it is
a div element). Don't forget to indent everything under #wrap to the left
once, since this project uses two spaces per block indentation.
How It Works (mini guides)
This section is intended for giving you a detailed explanation about
how a particular functionality works. Maybe you are just curious about
how it works, or maybe you are lost and confused while reading the code,
I hope it provides some guidance to you.
###Custom HTML and CSS Design 101
HTML5 UP has many beautiful templates that you can download for free.
When you download the ZIP file, it will come with index.html, images, css and js folders. So, how do you
integrate it with Hackathon Starter? Hackathon Starter uses Bootstrap CSS framework, but these templates do not.
Trying to use both CSS files at the same time will likely result in undesired effects.
Note: Using the custom templates approach, you should understand that you cannot reuse any of the views I have created: layout, home page, api browser, login, signup, account management, contact. Those views were built using Bootstrap grid and styles. You will have to manually update the grid using a different syntax provided in the template. Having said that, you can mix and match if you want to do so: Use Bootstrap for main app interface, and a custom template for a landing page.
Let's start from the beginning. For this example I will use Escape Velocity template:
Note: For the sake of simplicity I will only consider index.html, and skip left-sidebar.html,
no-sidebar.html, right-sidebar.html.
Move all JavaScript files from html5up-escape-velocity/js to public/js. Then move all CSS files from html5up-escape-velocity/css to public/css. And finally, move all images from html5up-escape-velocity/images to public/images. You could move it to the existing img folder, but that would require manually changing every img reference. Grab the contents of index.html and paste it into HTML To Jade.
Note: Do not forget to update all the CSS and JS paths accordingly.
Create a new file escape-velocity.jade and paste the Jade markup in views folder.
Whenever you see the code res.render('account/login') - that means it will search for views/account/login.jade file.
Let's see how it looks. Create a new controller escapeVelocity inside controllers/home.js:
I will stop right here, but if you would like to use this template as more than just a single page, take a look at how these Jade templates work: layout.jade - base template, index.jade - home page, partials/header.jade - Bootstrap navbar, partials/footer.jade - sticky footer. You will have to manually break it apart into smaller pieces. Figure out which part of the template you want to keep the same on all pages - that's your new layout.jade.
Then, each page that changes, be it index.jade, about.jade, contact.jade
will be embedded in your new layout.jade via block content. Use existing templates as a reference.
This is a rather lengthy process, and templates you get from elsewhere,
might have yet another grid system. That's why I chose Bootstrap for the Hackathon Starter.
Many people are already familiar with Bootstrap, plus it's easy to get started with it if you have never used Bootstrap.
You can also buy many beautifully designed Bootstrap themes at Themeforest, and use them as a drop-in replacement for Hackathon Starter. However, if you would like to go with a completely custom HTML/CSS design, this should help you to get started!
How do flash messages work in this project?
Flash messages allow you to display a message at the end of the request and access
it on next request and only next request. For instance, on a failed login attempt, you would
display an alert with some error message, but as soon as you refresh that page or visit a different
page and come back to the login page, that error message will be gone. It is only displayed once.
This project uses express-flash module for flash messages. And that
module is built on top of connect-flash, which is what I used in
this project initially. With express-flash you don't have to
explicity send a flash message to every view inside res.render().
All flash messages are available in your views via messages object by default,
thanks to express-flash.
Flash messages have a two-step process. You use req.flash('errors', { msg: 'Error messages goes here' }
to create a flash message in your controllers, and then display them in your views:
In the first step, 'errors' is the name of a flash message, which should match the
name of the property on messages object in your views. You place alert messages
inside if message.errors because you don't want to show them flash messages are actually present.
The reason why you pass an error like { msg: 'Error messages goes here' } instead
of just a string - 'Error messages goes here', is for the sake of consistency.
To clarify that, express-validator module which is used for validating and sanitizing user's input,
returns all errors as an array of objects, where each object has a msg property with a message
why an error has occurred. Here is a more general example of what express-validator returns when there are errors present:
[{param: "name",msg: "Name is required",value: "<received input>"},{param: "email",msg: "A valid email is required",value: "<received input>"}]
To keep consistent with that style, you should pass all flash messages
as { msg: 'My flash message' } instead of a string. Otherwise you will just see an alert box
without an error message. That is because, in partials/flash.jade template it will try to output
error.msg (i.e. "My flash message".msg), in other words it will try to call a msg method on a String object,
which will return undefined. Everything I just mentioned about errors, also applies
to "info" and "success" flash messages, and you could even create a new one yourself, such as:
Data Usage Controller (Example)
req.flash('warning', { msg: 'You have exceeded 90% of your data usage' });
partials/flash.jade is a partial template that contains how flash messages
are formatted. Previously, flash
messages were scattered throughout each view that used flash messages
(contact, login, signup, profile), but now, thankfully it is uses a DRY approach.
The flash messages partial template is included in the layout.jade, along with footer and navigation.
body
#wrapincludepartials/navigation.containerincludepartials/flashblockcontentincludepartials/footer
If you have any further questions about flash messages,
please feel free to open an issue and I will update this mini-guide accordingly,
or send a pull request if you would like to include something that I missed.
How do I create a new page?
A more correct way to be to say "How do I create a new route". The main file app.js contains all the routes.
Each route has a callback function associated with it. Sometimes you will see 3 or more arguments
to routes. In cases like that, the first argument is still a URL string, while middle arguments
are what's called middleware. Think of middleware as a door. If this door prevents you from
continuing forward, you won't get to your callback function. One such example is a route that requires authentication.
If you are authenticated, you let this visitor pass through your "door" by calling return next();. It then proceeds to the
next middleware until it reaches the last argument, which is a callback function that typically renders a template on GET requests or redirects on POST requests. In this case, if you are authenticated, you will be redirected to Account Management page, otherwise you will be redirected to Login page.
Express.js has app.get, app.post, app.put, app.delete, but for the most part you will only use the first two HTTP verbs, unless you are building a RESTful API.
If you just want to display a page, then use GET, if you are submitting a form, sending a file then use POST.
Here is a typical workflow for adding new routes to your application. Let's say we are building
a page that lists all books from database.
Step 1. Start by defining a route.
app.get('/books',bookController.getBooks);
Note: As of Express 4.x you can define you routes like so:
Use whichever style that makes sense to you. Either one is acceptable. I really think that chaining HTTP verbs on
app.route is very clean and elegant approach, but on the other hand I can no longer see all my routes at a glance
when you have one route per line.
Step 2. Create a new schema and a model Book.js inside the models directory.
Step 3. Create a new controller file called book.js inside the controllers directory.
/** * GET /books * List all books. */varBook=require('../models/Book.js');exports.getBooks=function(req,res){Book.find(function(err,docs){res.render('books',{books: docs});});};
Step 4. Import that controller in app.js.
varbookController=require('./controllers/book');
Step 5. Create books.jade template.
extendslayoutblockcontent.page-header
h3 All Books
ul
for book in books
li=book.name
That's it! I will say that you could have combined Step 1, 2, 3 as following:
Sure, it's simpler, but as soon as you pass 1000 lines of code in app.js it becomes a little difficult to navigate the file.
I mean, the whole point of this boilerplate project was to separate concerns, so you could
work with your teammates without running into MERGE CONFLICTS. Imagine you have 4 developers
working on a single app.js, I promise you it won't be fun resolving merge conflicts all the time.
If you are the only developer then it's fine. But as I said, once it gets up to a certain LoC size, it becomes
difficult to maintain everything in a single file.
That's all there is to it. Express.js is super simple to use.
Most of the time you will be dealing with other APIs to do the real work:
Mongoose for querying database, socket.io for sending and receiving messages over websockets,
sending emails via Nodemailer, form validation using express-validator library,
parsing websites using Cheerio, and etc.
How do I use Socket.io with this?
Dan Stroot submitted an excellent pull request that adds a real-time dashboard with socket.io.
And as much as I'd like to add it to the project, I think it violates one of the main
principles of the Hackathon Starter:
When I started this project, my primary focus was on simplicity and ease of use.
I also tried to make it as generic and reusable as possible to cover most use cases of
hackathon web apps, without being too specific.
When I need to use socket.io, I really need it, but most of the time - I don't. But more
importantly, websockets support is still experimental on most hosting providers. As of October 2013,
Heroku supports websockets, but not until you opt-in by running this command:
heroku labs:enablewebsockets-amyapp
And what if you are deploying to OpenShift? They do support websockets, but it is currently in a
preview state. So, for OpenShift you would need to change the socket.io connect URI to the following:
Wait, why is it on port 8000? Who knows, and if I didn't run across this blog post
I wouldn't even know I had to use port 8000.
I am really glad that Heroku and OpenShift at least
have a websockets support, because many other PaaS providers still do not support it.
Due to the aforementioned issues with websockets, I cannot include socket.io as part of the Hackathon Starter. For now...
If you need to use socket.io in your app, please continue reading.
First you need to install socket.io:
npminstallsocket.io--save
Replace var app = express(); with the following code:
I like to have the following code organization in app.js (from top to bottom): module dependencies,
import controllers, import configs, connect to database, express configuration, routes,
start the server, socket.io stuff. That way I always know where to look for things.
Add the following code at the end of app.js:
io.on('connection',function(socket){socket.emit('greet',{hello: 'Hey there browser!'});socket.on('respond',function(data){console.log(data);});socket.on('disconnect',function(){console.log('Socket disconnected');});});
One last thing left to change:
app.listen(app.get('port'),function(){
to
server.listen(app.get('port'),function(){
At this point we are done with the back-end.
You now have a choice - to include your JavaScript code in Jade templates or have all your client-side
JavaScript in a separate file - in main.js. I will admit, when I first started out with Node.js and JavaScript in general,
I placed all JavaScript code inside templates because I have access to template variables passed in from Express
right then and there. It's the easiest thing you can do, but also the least efficient and harder to maintain. Since then I
almost never include inline JavaScript inside templates anymore.
But it's also understandable if you want take the easier road.
Most of the time you don't even care about performance during hackathons, you just
want to "get shit done" before the time runs out.
Well, either way, use whichever approach makes more sense to you. At the end of the day,
it's what you build that matters, not how you build it.
If you want to stick all your JavaScript inside templates, then in layout.jade -
your main template file, add this to head block.
script(src='/socket.io/socket.io.js')script.
var socket =io.connect(window.location.href);
socket.on('greet', function (data) {
console.log(data);
socket.emit('respond', { message:'Hey there, server!' });
});
Note: Notice the path of the socket.io.js, you don't actually
have to have socket.io.js file anywhere in your project; it will be generated
automatically at runtime.
If you want to have JavaScript code separate from templates, move that inline
script code into main.js, inside the $(document).ready() function:
$(document).ready(function(){// Place JavaScript code here...varsocket=io.connect(window.location.href);socket.on('greet',function(data){console.log(data);socket.emit('respond',{message: 'Hello to you too, Mr.Server!'});});});
Let's suppose that each user has a votes field and you would like to count
the total number of votes in your database across all users. One very
inefficient way would be to loop through each document and manually accumulate
the count. Or you could use MongoDB Aggregation Framework instead:
Once you are ready to deploy your app, you will need to create an account with
a cloud platform to host it. These are not the only choices, but they are my top
picks. From my experience, Heroku is the easiest to get started with, it will
automatically restart your Node.js process when it crashes, zero-downtime
deployments and custom domain support on free accounts. Additionally, you can
create an account with MongoLab and then pick one of the 4 providers below.
Again, there are plenty of other choices and you are not limited to just the ones
listed below.
1-Step Deployment with Heroku
- Download and install [Heroku Toolbelt](https://toolbelt.heroku.com/)
- In terminal, run `heroku login` and enter your Heroku credentials
- From *your app* directory run `heroku create`
- Run `heroku addons:create mongolab`. This will set up the MongoLab add-on and configure the `MONGOLAB_URI` environment variable in your Heroku app for you.
- Lastly, do `git push heroku master`. Done!
Note: To install Heroku add-ons your account must be verified.
- Open [mongolab.com](https://mongolab.com) website
- Click the yellow **Sign up** button
- Fill in your user information then hit **Create account**
- From the dashboard, click on **:zap:Create new** button
- Select **any** cloud provider (I usually go with AWS)
- Under *Plan* click on **Single-node (development)** tab and select **Sandbox** (it's free)
- *Leave MongoDB version as is - `2.4.x`*
- Enter *Database name** for your web app
- Then click on **:zap:Create new MongoDB deployment** button
- Now, to access your database you need to create a DB user
- Click to the recently created database
- You should see the following message:
- *A database user is required to connect to this database.* **Click here** *to create a new one.*
- Click the link and fill in **DB Username** and **DB Password** fields
- Finally, in `.env` instead of `mongodb://localhost:27017/test`, use the following URI with your credentials:
- `db: 'mongodb://USERNAME:[email protected]:27479/DATABASE_NAME'`
Note: As an alternative to MongoLab, there is also Compose.
- First, install this Ruby gem: `sudo gem install rhc` 💎
- Run `rhc login` and enter your OpenShift credentials
- From your app directory run `rhc app create MyApp nodejs-0.10`
- **Note:** *MyApp* is the name your app (no spaces)
- Once that is done, you will be provided with **URL**, **SSH** and **Git Remote** links
- Visit provided **URL** and you should see the *Welcome to your Node.js application on OpenShift* page
- Copy and and paste **Git Remote** into `git remote add openshift YOUR_GIT_REMOTE`
- Before you push your app, you need to do a few modifications to your code
Add these two lines to app.js, just place them anywhere before app.listen():
app.listen(PORT,IP_ADDRESS,function(){console.log("Express server listening on port %d in %s mode",PORT,app.settings.env);});
Add this to package.json, after name and version. This is necessary because, by default, OpenShift looks for server.js file. And by specifying supervisor app.js it will automatically restart the server when node.js process crashes.
Finally, you can now push your code to OpenShift by running git push -f openshift master
Note: The first time you run this command, you have to pass -f (force) flag because OpenShift creates a dummy server with the welcome page when you create a new Node.js app. Passing -f flag will override everything with your Hackathon Starter project repository. Do not run git pull as it will create unnecessary merge conflicts.
The data model is comprised of all the Mongoose schemas in the models directory. In order to ensure stability, there are a few rules for modifying the data model. Please find the appropriate heading and follow the recommended steps.
Adding A Schema
Adding an object is always safe. New schemas may have required properties without default values because no data for this Schema exists in production yet. Adding default values is recommended for all properties that are not required.
Adding A Property
All new properties must have a default value. Without a default value, each brigade will need to run a migration on their MongoDb instance. This is a high cost that we can easily avoid. If a default value does not make sense, consider adding a new schema and performing a query instead.
Deleting A Property
Remove the property and all code that references the property in the same commit. This ensures that each commit can be safely and atomically pushed to production.
Deleting A Schema
Remove the schema and all code that references the property in the same commit. This ensures that each commit can be safely and atomically pushed to production.
1:1 feature parity with the current CfSF website. We build it as a replica, using the tools we have and implementing the appropriate content-management systems to maintain it as it is, but using the new auth and adding an admin backend. This will take the load off the W&T team for updating the content of the website, and at the very least, will be a good standalone application in its own right. Architecture should be built with additional features in mind, but focused on current website functionality. During this time, we should also be reaching out to other brigades, and seeing what it would take to entice them to make the move to brigadehub, and start adding those features to the next iteration enhancements.
The scope/goal for this release would be to replace the current CfSF website fulltime. Timeline currently is April 21st (refer milestones)
versioning: 1.x.x-alpha, 1.x.x-alpha.x, etc. (following semver)
We expand out features to include user onboarding, project matching, and any other additional functionality not currently present in website. This would include 1-click deployment to heroku, docker imaging, and any other devops-easing functionality as well. Theming should be included in this release. We should also be reaching out to other brigades during this time to see if anyone is willing to start playing with the application, and getting quality beta feedback for usage/features.
The scope/goal of this release would be to replace between 2-5 brigades websites, or at least have them install it to play with it. Timeline June 9th 2016
versioning: 1.x.x-beta, 1.x.x-beta.x, etc. (following semver)
Live
We expand our outreaching efforts, and try to get brigades across the globe to adopt the platform, actively talking with other leadership teams, and making sure to support/help when issues arise. We should be expanding out the theme library, with up to 5-6 separate themes for brigades to choose from, and perfect the deployment pipeline for the application. Additional discovery and feature expansion can be made after this point.
The scope/goal of this release, while lofty, would be to replace the websites of all brigades, or as many as we can get to adopt it. Timeline Aug 16th 2016.
versioning: 1.x.x-rc.1, 1.x.x, etc. (following semver)
