NB This post is no longer current. Please visit coralproject.net for the latest on how to contribute to our work.
Please join us in making communities around journalism better, stronger, safer, smarter.
We’ve started 2016 by moving almost all of the project into the open, creating many more ways for you to get involved in our work.
How do I get involved?
To contribute open-source code and learn more about our technical approach, visit our repos on GitHub. For example, here’s our ecosystem diagram and here’s our contributor guide.
To discuss community issues, strategies, and products, join our community forum, powered by the Discourse platform. For example, here’s where you can tell us what we should be building, and here’s where we share interesting reading about online communities.
To read more about our ideas, follow our blog and then share your thoughts in the forum. For example, here’s the page to talk about this blogpost.
To receive weekly(ish) updates, subscribe to our newsletter.
To apply to beta test our products, submit your publishing organization’s information here.
To send us a private note, email coralcommunity@
As we move forward, we will continually update our Get Involved page with information about current conversations, bugs, and other ways to contribute to our current thinking.
Are there any rules about contributing?
All contributors must agree to our code of conduct.
What does openness mean to The Coral Project?
(This response is based on a conversation within the Coral team. Our conversation was partly inspired by this blogpost from our Mozilla colleague Matt Thompson.)
Our goal is to increase the transparency of our work, as well as the number of people involved, so that:
• we can grow faster
• we can reach further
• we can build momentum
• we can benefit from more wisdom and insight
• we can test faster, and with more users
• we can get feedback on what we are doing and how
• we can find out if we’re asking the right questions
• we can create something sustainable
• we can be accountable to each other and our goals
• we can integrate more diverse needs and ideas into our work
• we can appeal to an existing and engaged group of people for ideas, fixes, suggestions
• we can do more
All of these reasons and more will make us work smarter and better. We also want our process and work to be shared and built upon by future projects.
In order to do this, we need to:
• document, explain, discuss openly what we’re doing and thinking
• create clear contribution paths
• create clear onboarding documents
• set clear expectations of behavior for ourselves and for our community members
• establish standards around where and how we invite community members to contribute to our work
• empower members of our community to talk and collaborate among themselves
• have a strategy for how we listen to, and accept code, feedback and ideas
• outline our workflow and our roadmap, and define clear, publicly available dates for what we’re working on when
• default to working open, and have a good reason why something needs to be private
• integrate our community into our user-centered design process, in which we have a hypothesis, we put it in front of users, we get information back and we analyze and then share the results.
We haven’t got all of these in place yet. We’re working on it – but from now on, out in the open.
What aren’t you sharing?
Proprietary information shared with us in confidence. Personal data and information. Information that could compromise the safety of our team or the security of our products. If there’s something you want to see that isn’t currently in our public documentation, let us know.
Did we miss anything? Do you have any suggestions?
Click here to visit the forum page related to this article. We’re excited to have you on the team.
Image by Alborzshawn, shared under CC-BY-2.0