Regular new re-implementations of the website

[jonnyscholes]

After discussing csszengarden style themes in #6 @joshgillies and I feel that regular complete overhauls of the website would be more feasible.

Eg When the current site is "completed" we tag it as release 1, fork it, re-evaluate content, design and implementation. Whoever wants to work on the next iteration contributes to the repo and its launched as the new design in a set period of time [~4 months perhaps?]. Rinse and repeat.

[joshgillies]

Totally agree, I think a model where a user forks this repo, hacks on their contribution to the next version of the design, and then submits a pull request to be included as the new current version of the site would work really well for what we're doing here.

This model will also get people familiar with using Git and Github based workflows, which will benefit everyone. 👍

[MattMS]

I'll be fighting for Jade, CoffeeScript and Stylus in the next quarter!

[jonnyscholes]

Jade, Typescript and Stylus?
On 27/03/2014 12:38 AM, "Matt McKellar-Spence" notifications@github.com
wrote:

I'll be fighting for Jade, CoffeeScript and Stylus in the next quarter!

Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-38683717
.

[joshgillies]

May the best PR win!

In all seriousness I think this should be a test bed for new workflows, technologies, and techniques. Build it in whatever you like!

I guess the only requirement would be that all source files are compiled so GH pages can serve them. Shouldn't be a problem thought with a sufficient workflow in place. For instance there's currently Sass being used for CSS, and we just need to remember to compile the .scss before making a commit.

[jonnyscholes]

True although for eeach release we'll have to settle on technologies.
Otherwise every time someone pulls they'll have to transpose the compiled
code changes back into their various preprocessors.
On 27/03/2014 12:36 PM, "Josh Gillies" notifications@github.com wrote:

May the best PR win!

In all seriousness I think this should be a test bed for new workflows,
technologies, and techniques. Build it in whatever you like!

I guess the only requirement would be that all source files are compiled
so GH pages can serve them. Shouldn't be a problem thought with a
sufficient workflow in place. For instance there's currently Sass being
used for CSS, and we just need to remember to compile the .scss before
making a commit.

Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-38760707
.

[joshgillies]

No. I mean in the same way we have the source scss and the compiled css in the current repo, this is how it would ideally be run in the future. Only pushing compiled assets is in this instance is daft.

A good place to start might be rolling a typical workflow into the existing code base as a proof of concept and to offer direction for future developments.

[jonnyscholes]

So basically do what we're doing now but use a set of predetermined
technologies and ensure it's documented in the readme. I guess we work
those out in the days after we make the fork for the next release. Sounds
dandy to me.

[MattMS]

I think a README covering how to play with the code-base (in any state) is essential.
It doesn't have to be fancy, most of the preprocessors will have compile commands and if someone wants to go all out they can study up on Grunt or whatever.

[jonnyscholes]

For sure. I put up a new issue [#13] for us to discuss what people would like to use next time round. Technologies to use as well as workflow [ie I'd love to use audio api somehow and I'm sure gillies would to].

[MattMS]

+1 for showing off an implemented audio API.
-1 if that audio auto-plays or is annoying in any way.

[jonnyscholes]

+10 to a singing bobble head of all the contributors
On 27/03/2014 11:50 PM, "Matt McKellar-Spence" notifications@github.com
wrote:

+1 for showing off an implemented audio API.
-1 if that audio auto-plays or is annoying in any way.

Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-38798328
.

[MattMS]

It could be a way to encourage sponsorship by providing that as the only escape from the singing heads. Malware may be involved to ensure leaving the page doesn't stop the heads.