Depends on #3

This will be an event but in the "draft" state.

On the legacy site, this is made of up many submodules which probably makes for an easier documentation update. In the initial release, we will just have one content page for the whole organizing guide, and attack breaking it up into submodules later.

The things needed to do this are:

• Create archetype for a blog post
• Create template for blog post list style
• Create template for blog post single style

http://www.devopsdays.org/events/2015-template/program/

I think it's because it's not wrapped in a col div.

Currently, the code will display nothing for a sponsor type if there are no sponsors of that type. On many existing sites, if there is a "Gold" level, for example, with no gold sponsors, a link will be displayed that says "become the first Gold sponsor"

I think this can be handled by slightly changing the formatting of the sponsor data in the event data file, but it might require a little more cleverness in the parsing on the event template to determine which things to show.

Should add fields for CFP opening and CFP closing

The current large footer is not going to scale well once we have another year :)

Also, it's tricky to update

This is a low priority, but once we have the format down, we should create a pair of shell (and Powershell) scripts that can be used to generate a new event, taking in just the year and city name, etc.

In psuedocode, something like this (taking $YEAR and $CITY as arguments or something)

hugo new events/$YEAR-$CITY/welcome.md --kind event
hugo new events/$YEAR-$CITY/program.md --kind event
hugo new events/$YEAR-$CITY/contact.md --kind event
hugo new events/$YEAR-$CITY/conduct.md --kind event
.
.
.
cp data/events/TEMPLATE.yml data/events/$YEAR-$CITY.yml

http://gohugo.io/

Seems to tick a number of boxes (though I've never used it myself):

• Modern; actively maintained.
• Static binary (instead of Ruby dependency / version hell).
• Some sort of template mechanism.
• Supports Markdown out of the box.

What's more, @mattstratton has operational experience with it, so that'd certainly be helpful.

That said, if there's something that's better, I'm not married to Hugo - worth looking at though!

This will help previewing changes without the need for running Hugo. WYSIWYG style.

The general idea is:

• master branch would be build and copied into the main location - http://devopsdays.github.io
• any non master branch or PR should be build and copied into staging area -http://devopsdays.github.io/<branch/PR_name>

So it would be possible to review the changes not only by the content, but by how it actually looks live in your web browser.

https://developers.google.com/analytics/devguides/collection/analyticsjs/creating-trackers#specifying_fields_at_creation_time

The idea here is that the main DOD tracker code will always be inserted, and events can add their own in the config file for the event, which would be added if it exists.

Have to figure out how to filter through the range of current events to determine the last one in the range, so it won't output the pipe

This will drive the map generation. We will edit the partials/maps.html file to pull in from upcoming events and populate.

http://www.devopsdays.org/pages/open-space-format/

• Test site build on hugo 0.15
• Ensure that our wercker workflow is using hugo 0.15
• Update README to specify that you need hugo 0.15

Per Bridget, an event can be on the site without dates. We will need to account for handing events with blank dates as being "future" events as well.

http://www.devopsdays.org/pages/organizing/charity/index.html

Unless we name the city WashingtonDC, it will bail. It doesn't like the dashes.

http://www.devopsdays.org/events/calendar/

Migrate data from all past events (2015 and before) to new system.

Here is an attempt of a list of all the events needed to migrate, so we can track.

• 2009
  • Ghent 2009
• 2010
  • Sydney 2010
  • Mountain View 2010
  • Hamburg 2010
  • Sao Paulo 2010
• 2011
  • Boston 2011
  • Mountain View 2011
  • Melbourne 2011
  • Bangalore 2011
  • Göteborg 2011
  • Manila 2011
• 2012
  • Austin 2012
  • Tokyo 2012
  • Delhi 2012
  • Mountain View 2012
  • Rome 2012
  • New York 2012
• 2013
  • New Zealand 2013
  • London 2013
  • Paris 2013
  • Austin 2013
  • Berlin 2013
  • Amsterdam 2013
  • Silicon Valley 2013
  • Downunder 2013
  • Bangalore 2013
  • London Autumn 2013
  • Barcelona 2013
  • Vancouver 2013
  • Portland 2013
  • New York 2013
  • Atlanta 2013
  • Tel Aviv 2013
  • Tokyo 2013
• 2014
  • Nairobi 2014
  • Ljubljana 2014
  • Austin 2014
  • Pittsburgh 2014
  • Amsterdam 2014
  • Silicon Valley 2014
  • Minneapolis 2014
  • Brisbane 2014
  • Boston 2014
  • Toronto 2014
  • New York 2014
  • Warsaw 2014
  • Chicago 2014
  • Berlin 2014
  • Belgium 2014
  • Helsinki 2014
  • Vancouver 2014
  • Tel Aviv 2014
  • Bangalore 2014
• 2015
  • Ljubljana 2015
  • Paris 2015
  • Denver 2015
  • New York 2015
  • Austin 2015
  • Toronto 2015
  • Washington, DC 2015
  • Amsterdam 2015
  • Minneapolis 2015
  • Melbourne 2015
  • Pittsburgh 2015
  • Chicago 2015
  • Bangalore 2015
  • Boston 2015
  • Tel Aviv 2015
  • Singapore 2015
  • Berlin 2015
  • Charlotte 2015
  • Silicon Valley 2015
  • Detroit 2015
  • Ohio 2015
  • Warsaw 2015

Currently, we list the events at the top of the homepage and use Scratch to slice and determine when to stop adding the dash at the end. Investigate if there is a more elegant way to perform this.

Depends on #49

It might be useful to be able to abstract out sponsors for use by multiple events, for example having a data/sponsors directory with a chef.yml, etc, for anyone who wanted to have Chef as a sponsor (that data file could contain the URL to link to, and the image path, although it would be more ideal just to name them in conjunction with each other).

Downside is if logos change from year to year, but you can still repurpose the instance of that sponsor.

http://www.devopsdays.org/pages/ignite-talks-format/

We need to refactor the template and the data TOML for event so that it can support however many tiers of sponsors an event wants

File should live in data/events and be named YEAR-CITY.yml

Should contain various items such as sponsors, twitter, etc, that will drive lower level pages

GA tag is UA-9713393-1

Not sure if this should be data driven, or if events will just write this out in their "submit a CFP" page by hand

There should be a SAMPLE.yml that will let organizers copy from when creating their event, if they decide to not use the setup script that will be created with #8

This one can be slightly tricky as we want them in a date format so we can know when they are over; perhaps two fields - start date and end date. That supports events that are not just two days long.

This will allow us to set BaseURL to localhost for local dev and the proper one in production

See https://github.com/ArjenSchwarz/wercker-step-hugo-build

http://www.devopsdays.org/events/2016-template/conduct/

This page exists on the legacy site, but not linked to in main nav. Should add it to main nav as well.

This is very old style of doing websites. I think the top banner should be converted to CSS/HTML.

Currently contains information about Arrested DevOps facebook page (devopsdays is a group, not a page, but it might work better to create a FB page for this...investigate)

There should be a SPONSOR.yml file that can be used as a template for new sponsors.

See https://discuss.gohugo.io/t/cant-insert-shortcode-parameter-without-quotation-marks/1481/6