Merge pull request #175 from devopsdays/bridget-explain-event-creation

Explanation of event creation.

README.md

@@ -5,43 +5,45 @@ You can see progress on tasks at http://waffle.io/devopsdays/devopsdays-web
 [![Throughput Graph](https://graphs.waffle.io/devopsdays/devopsdays-web/throughput.svg)](https://waffle.io/devopsdays/devopsdays-web/metrics)
 
 # devopsdays-web
-This is the website for DevOpsDays.org
+This is the website for devopsdays.org
 
 ## Contributing
 
-Here are the steps to follow to get going as an DevOpsDays content contributor (or heck, even a code contributor)
+If you'd like to edit a specific devopsdays event site (and/or contribute code), here's how to get started:
 
+### Setup
 1. Install [Hugo v0.15+](http://gohugo.io)
-2. Fork this repo
-3. If you want to fire up a local copy to see your changes as you go, enter this command `hugo server -w --baseUrl="http://localhost:1313"`
-4. The `--baseUrl` flag is kind of flaky, so a good solution is to change the `config.toml` file to point to `localhost` before starting `hugo server -w`. DO NOT COMMIT THIS CHANGED FILE BACK TO GITHUB. Just exclude it for now. We don't add it to `.gitignore` because we might need to muck with that file...although once everything is stable we might do this for safety.
-4. You probably want to do the previous thing in another pane/window, as it needs to keep running. The -w watches for any changes and rebuilds on the fly.
-4. Before you make any changes, create a new branch, i.e., `git checkout -b fix-that-thing`
-5. Make your changes, test them locally, then push that branch up to origin (`git push origin BRANCHNAME`)
-6. Submit a pull request from the branch you just pushed
-7. Ideally, this will be reviewed by someone else, but if you have commit bit on this repo and feel bold, approve it yourself :)
-5. When you merge to master on github, wercker will automatically build the site and publish it to [http://devopsdays.github.io](http://devopsdays.github.io).
+1. Fork this repo
+1. To watch for changes and rebuild on the fly, open a new terminal, cd to your fork of the repo, and enter this command: `hugo server -w --baseUrl="http://localhost:1313"`
+
+### Contribute changes
+1. Code changes that affect the overall site will be reviewed only if they are in a separate pull request from any event-specific content. tl;dr: don't add "giant template change" in the same PR as "here are some more sponsors". If it affects anything other than your event, it should be in its own PR.
+1. We use [github issues](https://github.com/devopsdays/devopsdays-web/issues) to track work, so feel free to create new ones if you like (or read/comment on existing ones).
+1. Before you commit any changes, create a new branch, i.e., `git checkout -b fix-that-thing`
+1. Make your changes, test them locally, then push that branch up to origin on your fork (`git push origin BRANCHNAME`)
+1. Submit a pull request from the branch you just pushed
+1. When a commit is merged to master on github (ideally via a PR reviewed by at least one other person), wercker will automatically build the site and publish it to [http://devopsdays.github.io](http://devopsdays.github.io).
 
 ## Creating a new event
 
-This is by no means complete, but a couple things to know:
+The easiest way to create a new event is with the [make_new_event.sh](https://github.com/devopsdays/devopsdays-web/blob/master/make_new_event.sh) script. Create a branch, run the script to make a skeleton site for your event, make any desired edits, and submit a PR as explained above.
+
+1. If your city name has special characters or diacritics, the script will remove them when it creates the event stub.
+1. Events need a data file in `data/events`, for example, `data/events/2015-chicago.yml`. It must be the same name as the directory you will create for your event. See the [template data file](https://github.com/devopsdays/devopsdays-web/blob/master/yyyy-city.yml) for an example.
+1. When the script copies the content directory from the sample site to `content/events/YYYY-city`, it removes `draft = true` from the frontmatter of the pages (so they will be built). Also, the `welcome.md` file needs to have a field added to its frontmatter for the alias, i.e., `aliases = ["/events/2015-chicago"]`.
+
+Once you have created a logo graphic, you will want to add it to the following directory (creating the directory if necessary) `/static/events/yyyy-city/logo.png`. The file MUST be called `logo.png`.
+
+## Adding sponsors
 
-1. Create a data file for your event in `data/events`, for example, `data/events/2015-chicago.yml`. It must be the same name as the directory you will create for your event. It should follow the format of `yyyy-city.yml`. It is highly recommended to just duplicate one from another event. A sample version can be found [here](https://github.com/devopsdays/devopsdays-web/blob/master/yyyy-city.yml)
-2. You can either copy the files from the `/content/events/sample-event` directory into a directory named `/content/events/YYYY-city`, or do it manually as listed below. If you copy from the sample site, please remove `draft = true` from the frontmatter of the pages (or they won't be built)
-3. Generate the pages for your event, in the following manner for each page. `hugo new events/2016-kiel/welcome.md --kind=event`
-4. The `welcome.md` file needs to have a field added to its frontmatter for the alias, i.e., `aliases = ["/events/2015-chicago"]`
-5. Sponsors each need a file in the data directory, as such: `data/sponsors/chef-2016.yml`. Please make sure to use the year for the sponsor (just so that the old events don't end up with newer sponsor logos, etc - but don't make one just for your city). If there is an existing sponsor and you can use it, you do not need to create the data file (or the image). If your information is different, please create a new file, such as `data/sponsors/chicagochef-2016.yml`.  (Note: there is an experimental feature for an "override" of the sponsor data; more on this feature as it is developed)
-6. Put the images for your sponsors in the `/static/img/sponsors` directory. They need to be PNG files and named exactly after the name of the sponsor in your event file (and the corresponding sponsor data file), i.e., `/static/img/sponsors/chef.png`.
-7. You will also want to add your event's logo to the following directory (creating the directory if necessary) `/static/events/yyyy-city/logo.png`. The file MUST be called `logo.png`.
+Sponsors each need a file in the data directory, as such: `data/sponsors/chef-2016.yml`. Please make sure to use the year for the sponsor (just so that the old events don't end up with newer sponsor logos, etc - but don't make one just for your city). If there is an existing sponsor and you can use it, you do not need to create the data file (or the image). If your information is different, please create a new file, such as `data/sponsors/chicagochef-2016.yml`.  (Note: there is an experimental feature for an "override" of the sponsor data; more on this feature as it is developed)
 
-## Sponsor logo guidelines
+Put the images for your sponsors in the `/static/img/sponsors` directory. They need to be PNG files and named exactly after the name of the sponsor in your event file (and the corresponding sponsor data file), i.e., `/static/img/sponsors/chef.png`.
 
 There are a few simple guidelines regarding sponsor logo files and formatting:
 
 * The dimensions of the image file must be 200px square.
 * The background must be either white or transparent.
 * There must *not* be a border.
 
-For reference, the all logos will be constrained, via markup, to 100px square;
-combined with the image file dimensions, this allows for high-density displays
-(ex. Retina). Lastly, a border will be drawn around the logo using CSS.
+All logos will be constrained, via markup, to 100px square; combined with the image file dimensions, this allows for high-density displays (ex. Retina). A border will be drawn around the logo using CSS.