Quick links: Our License • Making Contributions • Atlas Builds
Data + Design is licensed under the terms of a Creative Commons BY-NC-SA license. The full legal code is at the link, but here's a quick human-readable breakdown for you as well. (Note: This is only a human-readable summary of, and not a substitute for or supplement to, the license.)
If you use this book yourself, credit us! Basically, you just need to include a little snippet saying:
Adapted from Data + Design by Trina Chiasson and Dyanna Gregory. Licensed under a Creative Commons BY-NC-SA 4.0 license. This work is not affiliated with or endorsed by the original authors.
About all you're saying is, "Hey, this was originally made by these peeps, go check it out. Any edits to this were made by me, not them." Pretty reasonable, right?
If you fork and make edits to this book, you can't do it for monetary gain. The purpose of this book is to help people make better-informed decisions in collecting, analyzing, and presenting their data. And to do that free availability of this book is kind of a big deal. So don't sell it, mmkay?
Finally, your version has to be licensed under the same terms as this one is. No telling people they can sell their derivatives, no telling people they don't have to attribute back to the original. Basically, just keep everything free and open.
Of course there are edge cases. There are times when you're just not going to be sure if doing X or Y will be kosher with the license or not. That's fine! Just open an issue on GitHub and let us know what's up. We'll talk it over and help you figure out if what you want to do is cool beans or if you should tweak your plans a little bit. It never hurts to ask!
Quick links: Our License • Making Contributions • Atlas Builds
Of course you can! That's part of the reason we're making this book totally openly sourced. We love when the community takes the time and effort to contribute to things like this. There are three different routes we recommend, depending on what you want to do.
This is the best option if you want to go off in your own direction, or just want your own copy of the source for reference, or generally just don't think that you're in the mood to add a new chapter. For most people, this is the best option.
What's even better? This is super easy to do. Just go to the repository and click Fork in the upper right corner. Voila! You're now the proud owner of a brand spanking new Data + Design repository.
Please note that we are keeping the project's CSS in a separate repository (link). You'll need this if you want to generate your own builds of the book. Likewise, if you see HTML elements and CSS classes that don't look familiar, that's likely because the book is maintained according to HTMLBook specifications.
Hey, wait a minute! What's up with this? It's just the same thing all over again!
Whoops. You got us there. As it turns out, the first step is the same for both people who want to contribute back to our repo and those who don't: you just gotta fork it.
But alright, let's say you've got a great idea for a new chapter. What's the process for getting it accepted and published look like? Well,
- Fork the main repository and keep it synced.
- Open an issue with us and label it as a question. Let everyone know what you're thinking. Even if you have a great chapter idea, we can't guarantee that there's a good spot in the book to put it and we don't want you spending hours of your time writing something that we'll end up rejecting. Get feedback on the idea and make sure that it'll be a chapter we can use.
- Start authoring! Here's where your fork comes in handy: you'll be making all chapter edits there.
- Get reviewers. Go back to your GitHub issue, check with the commenters there, and see who would be willing to review your chapter for content, grammar, and style. Add them as contributors on your fork, let them make edits, etc.
- Once you all think that the chapter's in a good place, create a pull request back to the main repository. That's when we'll go through and do an 'official' edit and suggest any changes we'd like to see before accepting your chapter.
- Publish! We'll accept your pull request and you'll offically have a chapter in Data + Design Congratulate yourself on a job well done and make sure that we didn't forget to add your information to our page of contributors.
We realize that not everyone knows how to use GitHub or wants to learn how to. And that's fine! If you don't want to worry about HTMLbook specifications and forks and pull requests and all that jazz, we've got your back. The process is conceptually similar to Option #2:
- Open an issue with us and label it as a question. Let everyone know what you're thinking. Even if you have a great chapter idea, we can't guarantee that there's a good spot in the book to put it and we don't want you spending hours of your time writing something that we'll end up rejecting. Get feedback on the idea and make sure that it'll be a chapter we can use.
- Make a Google Doc and start authoring! If you don't have a Google account, we're sorry, but you'll just have to bite the bullet and create one. We'd like to cover every major email provider in the world, but that's not terribly practical.
- Get reviewers. Share your document with [email protected] and we'll get you in contact with some editors who are currently available. Make sure that you give us full editing rights so that we can add editors for you!
- Once you all think that the chapter's in a good place, drop us a line at [email protected]. We'll go through and do an 'official' edit and suggest any changes we'd like to see before accepting your chapter.
- Publish! We'll handle all the behind-the-scenes stuff to convert your chapter to HTML and add it to the published book. Congratulate yourself on a job well done and make sure that we didn't forget to add your information to our page of contributors.
Let's say you go through the whole process of proposing, authoring, editing, and submitting a new chapter and we reject it. What happens next?
Well, that'll depend on your exact situation. It might be that we don't think the chapter is written to the standards of the rest of the book. If that's the case, revising and resubmitting is nearly always going to be an option. See if you can get input from someone whose chapter has been accepted; get another couple rounds of edits. And then edit it some more for good measure. Then go ahead and resubmit and see what happens!
Alternately, it might end up that the chapter that was proposed and the chapter that was delivered are significantly different—to the point that your delivered chapter isn't a great fit for the book. If that's the case, don't despair: you've still written a great chapter and can publish it on your forked repo. We're sorry that it didn't work out, but ask for feedback and see what needs to be changed for it to be accepted as an official addition.
Or for some entirely other reason that we can't predict, we might reject your chapter without the chance to revise and resubmit. If and when this happens, we're sorry. (Legitimately, we don't get any sick joy out of this!) We try to put quality checks in place to prevent this from happening at all, but we can't catch everything. Regardless, you're always encouraged to make whatever edits you would like to your forked repository: after all, that sort of personalization and community involvement is why we open sourced this in the first place.
That said, the best strategy is to just be proactive about your submission: get feedback early and get feedback often. This book was written by so many incredibly dedicated individuals, you shouldn't have any difficulty getting good, constructive feedback at every stage of the writing process. Take advantage of this. Even if we don't end up accepting your chapter, it'll still be something to be proud of having written.
Quick links: Our License • Making Contributions • Atlas Builds
[[In Progress]]
Although, yes, we already have an HTML structure for the book, we still use an external platform to publish it. O'Reilly's Atlas allows us to take our book and publish it to a finalized (and slightly prettied-up) HTML version as well as to PDF, MOBI, and EPUB formats.
Now, if you're making an official contribution to our repository, this probably isn't too important to you since we'll be handling the actual releases. However, if you're striking it out on your own, you might want an easy way to publish your book to multiple print and web platforms. Once you've finalized the edits to your forked repo, sign up for a free trial at the link above and you'll have the option to import your repository. As long as you've kept everything to HTMLbook spec, Atlas should be able to process the book without a hitch when you go to build a final release.
Note: You can also author directly in Atlas using a nice, friendly GUI (much like authoring in Google Docs or using Microsoft Word). You'll still need to import the pre-existing book, but once that's done it's super easy to add your content using Atlas's visual editor.