Thanks for wanting to contribute to Open Design. This is not the typical open source project— we do need code contributions, but we are also looking for UX Design, UI Design, Information Architecture, and Content Strategy contributions. More than anything, we want to help more people recognize the benefits of collaborating in the open. We recognize there are barriers to entry for these less common open source contributors, so in addition to working with experienced contributors, we want to help people with their first contributions and pull requests. If at any point you have any questions, or need some help, please don't hesitate to contact us.
The fastest way to get ahold of us is to ping us on twitter @designopen @garthdb @una @terracomma. If you'd prefer, you could jump into our Slack team; join here. If you want to talk about an issue or propose a feature, start a GitHub issue. Finally, if you like email, you can contact Garth at garthdb@gmail.com, he's probably looking for a distraction from something he should be doing.
These are just recommended steps, if you have a different, preferred workflow, use it; the most important part about this project is enjoying the work. Whether you're contributing code (through pull requests), design, or content, these general steps should apply. Check out more granular directions below for the individual contribution types.
If you have a particular set of skills that would lend itself well to Open Design, we want you. If you want to get experience in a new field (design, developer, writing, or something totally different) we want you; this is a safe space for experimentation. Read through the existing GitHub issues to see if something interests you. If someone has already started work on an issue or feature, that doesn't mean you can't help, it just means we get to collaborate. Jump into the discussion and let us know you're interested.
To make sure we aren't stepping on each other's toes, it's a good idea to contact us about your work before you start doing work. We recommend starting a GitHub issue so everyone can participate in the conversation, but feel free to contact us through any of the channels mentioned above.
If you want to start on a big feature, consider breaking it up into smaller GitHub issues. Things are more likely to be finished if they are bitesize. Once you do start work, share you progress along the way. Periodically post updates in your issues to let everyone know how things are going. Add screenshots whenever possible. Ask questions. Ask for advice/help if you ever get stuck. Post random animated gifs. We just like hearing from you.
Let us know when you're done and post something about the final version in the issue. Close the issue, if you can, or ask a core contributor to close it out.
The easiest way to contribute is to fork the repo to your personal account, and finish with a pull requests. Feel free to check in along the way, before the pull request. If you're going to make a couple contributions we're happy to give you commit access to the repo. In our contributor team we work on branches for each feature/issues and make pull requests to master; branches are easier for collaboration than forks. We like to have all contributions reviewed by a core contributor before being accepted; no one should commit directly to master nor accept their own pull request.
We try to have automated tests on all our projects. Before making a pull request, verify that your tests are passing locally first. For the main project you run the tests locally by running the command $ bundle exec rake test in the project. If you've hit an issues with the tests, let us know.
There isn't a perfect way to contribute design. We are not exclusive on file format or design tool. Work with whatever you want. We've found success using Pixelapse for collaborating; we can add you to the project if that helps. If you prefer something else, we are open. Whatever you do, post screenshots and ideas often.
A good place to start designing (low hanging fruit), is to make a custom design for an article that is still using the default template. We have a way to add custom design to each article (a lá CSS Zen Garden); check out the post design tagged issues. You can just provide a design for an article, or even go as far as writing the front end code. We'll fill in any gaps. The articles are designed to be modular; you don't have to match the style of anything else on the site. We'd prefer the design to work well with the content of the article. We do have a universal header and elements of a footer we'd like every article to keep, to make site navigation easier.
If you have more big picture ideas, get us in the loop early and we can talk it out.
To be honest, we don't have a great collaborative workflow for writing articles/content. We have used Google Docs, Draft, etc. but we aren't fully committed to any one solution.
If you're tackling something big, outlines can be helpful; send us your outline and drafts along the way.
Like any other contribution, every article is reviewed/edited by a core contributor before being published. All edits are discussed with the author before publishing.
Ultimately the article will be formatted using markdown, so it's the preferred format, but we'll accept anything we can convert.
We love you for wanting to help out. Use Open Design as an excuse to try something new and add some new skills and tools to your toolbelt.
Making a contribution does not commit you to the project forever. We'd love you to stick around, but we know life gets busy and new projects pop up.
If at any point you doubt your ability, or availability, to be able to finish something you've started, let us know. We'll help you through it, or transfer your work to someone else. The sooner you let us know, the better.
Love, The Open Design Directors (Garth Braithwaite, Christopher Moody, Una Kravets)