Zulip is the world's most productive group chat, and an open-source project with over 300 contributors since its start in 2015. With the right techniques, a high standard of code quality helps us welcome newcomers and equip them to meet the same standard — which is great for the people, and great for the software. Other projects — both open-source and not — can benefit from our techniques.

[Zulip](https://zulipchat.com/) is the world's most productive group chat — an open-source alternative to Slack, with a threading model like email that lets you skip irrelevant conversations without missing important ones. Since Zulip began as an open-source project in September 2015, it's [welcomed](https://github.com/zulip/zulip) hundreds of contributors; the [Zulip Server 1.6 release](https://blog.zulip.org/2017/06/06/zulip-server-1-6-released/) in June 2017 contained the work of over 300 people, including 3100 new commits by over 150 different people just since version 1.5 in February. All this was done with a full-time core team of no more than 5 people — and yet instead of getting slowed down as more new people get involved, or lowering quality levels, the project only develops faster and raises our standard of quality. How have we done such a thing? * We insist on clear, high-quality code — helping everyone understand the code, and helping new people become productive faster. * We've written extensive [developer documentation](http://zulip.readthedocs.io/en/latest/) to get the "lore" that developers in any codebase rely on out of individuals' heads and make it accessible to everyone. * We've taken the time to script, document, and thoroughly debug a reliable [development environment](http://zulip.readthedocs.io/en/latest/dev-overview.html) setup process — virtually eliminating a common source of major frustration and wasted time for new and would-be contributors to a project. * We use static types — with [mypy](https://blog.zulip.org/2016/10/13/static-types-in-python-oh-mypy/) for Python, and we're now converting our web and mobile JavaScript codebases to TypeScript and Flow — to add an extra level of clarity to our code to help everyone read and understand it better. * We maintain an extensive test suite — unit tests, end-to-end tests, backend, frontend — to help give us confidence in merging a pull request. * We've built [zulipbot](http://zulip.readthedocs.io/en/latest/zulipbot-usage.html), a GitHub workflow bot which lets us fill in gaps in how GitHub works, most notably to democratize the workflow for all contributors. I'll discuss each of these, with an emphasis on techniques and lessons that can be applied in other projects — not only open-source projects, but also how most of our techniques can help a closed team inside a company work better, too.