Zulip 2016 Roadmap¶
Zulip has received a great deal of interest and attention since it was released as free and open source software by Dropbox. That attention has come with a lot of active development work from members of the Zulip community. From when Zulip was released as open source in late September 2015 through today (mid-April, 2016), over 300 pull requests have been submitted to the various Zulip repositories (and over 250 have been merged!), the vast majority of which are submitted by Zulip’s users around the world (as opposed to the small core team that reviews and merges the pull requests).
In any project, there can be a lot of value in periodically putting together a roadmap detailing the major areas where the project is hoping to improve. This can be especially important in an open source project like Zulip where development is distributed across many people around the world. This roadmap is intended to organize a list of the most important improvements that should be made to Zulip in the relatively near future. Our aim is to complete most of these improvements in 2016.
This document is not meant to constrain in any way what contributions to Zulip will be accepted; instead, it will be used by the Zulip core team to prioritize our efforts, measure progress on improving the Zulip product, hold ourselves accountable for making Zulip improve rapidly, and celebrate members of the community who contribute to projects on the roadmap.
If you’re someone interested in making a larger contribution to Zulip and looking for somewhere to start, this roadmap is the best place to look for substantial projects that will definitely be of value to the community (if you’re looking for a starter project, see the guide to getting involved with Zulip).
We occasionally update this roadmap by adding strikethrough for issues that have been resolved.
Without further ado, below is the Zulip 2016 roadmap.
The top problem for the Zulip project is the state of the mobile apps. The Android app has started seeing rapid progress thanks to a series of contributions by Lisa Neigut of Recurse Center, and we believe it is on a good path. The iOS app has fewer features than Android and has more bugs, but more importantly is in need of an experienced iOS developer who has time to drive the project.
Update: Neeraj Wahi is leading an effort on to write a new React Native iOS app for Zulip to replace the old iOS app.
Core User Experience¶
This category includes important improvements to the core user experience that will benefit all users.
Improve missed message notifications to make “reply” work nicely
- Add support for showing “user is typing” notifications
- Add pretty bubbles for recipients in the compose box
Finish and merge support for pinning a few important streams
- Display stream descriptions more prominently
- Integration inline URL previews
- Add support for managing uploaded files
- Make Zulip onboarding experience smoother for teams not used to topics. That specific proposal might not be right but the issue is worth investing time in.
Ease of setup and onboarding issues¶
This category focuses on issues users experience when installing a new Zulip server or setting up a new Zulip realm.
- Create a web flow for setting up a new realm / the first realm on a new server (currently, it’s a command-line process)
- Document or better script solution to rabbitmq startup issues
- Add a mechanism for deleting early test messages
- Merge a supported way to use Zulip in Docker in production implementation.
The core Zulip UI has been mostly translated into 5 languages; however, more work is required to make those translations actually displayed in the Zulip UI for the users who would benefit from them.
User Experience at scale¶
There are a few parts of the Zulip UI which could benefit from overhauls designed around making the user experience nice for large teams.
Administration and management¶
Currently, Zulip has a number of administration features that can be controlled only via the command line.
Zulip should support 10000 users in a realm and also support smaller realms in more resource-constrained environments (probably a good initial goal is working well with only 2GB of RAM).
Performance is essential for a communication tool. While some things are already quite good (e.g. narrowing and message sending is speedy), this is an area where one can always improve. There are a few known performance opportunities:
Zulip should be making use of the best Python/Django tools available.
- Add support for Zulip running on Python 3
- Add support for changing users’ email addresses
- Automatic thumbnailing of uploaded images
- Upgrade Zulip to use Django 1.10 once it is released. The patches needed to run Zulip were merged into mainline Django in Django 1.10, so this will mean we don’t need to use a fork of Django anymore.
While the Zulip server has a great codebase compared to most projects of its size, it takes work to keep it that way.
- Migrate most web routes to REST API
- Finish deprecating and remove the pre-REST Zulip /send_message API
- Split Tornado subsystem into a separate Django app
- Clean up clutter in the root of the zulip.git repository
- Refactor zulip.css to be broken into components
Deployment and upgrade process¶
- Add support for 2-factor authentication on all platforms
- Add a retention policy feature that automatically deletes old messages
- Upgrade every Zulip dependency to a modern version
- The LOCAL_UPLOADS_DIR file uploads backend only supports world-readable uploads
- Add support for stronger security controls for uploaded files
- Extend Zulip’s automated test coverage to include all API endpoints
- Build automated tests for the client API bindings
- Add Python static type-checking to Zulip using mypy
Improve the runtime of Zulip’s backend test suite Use caching to make Travis CI runtimes faster
- Add automated tests for the production upgrade process
Improve Travis CI “production” test suite to catch more regressions
- Significantly expand documentation of the Zulip API and integrating with Zulip.
- Expand library of documentation on Zulip’s feature set. Currently most documentation is for either developers or system administrators.
- Expand developer documentation with more tutorials explaining how to do various types of projects.
- Overhaul new contributor documentation, especially on coding style, to better highlight and teach the important pieces.
- Update all screenshots to show the current Zulip UI
Integrations are essential to Zulip. While we currently have a reasonably good framework for writing new webhook integrations for getting notifications into Zulip, it’d be great to streamline that process and make bots that receive messages just as easy to build.
Make it super easy to take screenshots for new webhook integrations
- Add an outgoing webhook integration system
Build a framework to cut duplicated code in new webhook integrations
- Make setting up a new integration a smooth flow
Optimize the integration writing documentation to make writing new ones really easy.
The Zulip Android app is ahead of the iOS app in terms of feature set, but there is still a lot of work to do. Most of the things listed below will eventually apply to the iOS app as well.
Support using a non-zulip.com server
- Support Google authentication with a non-Zulip.com server
- Add support for narrowing to @-mentions
- Support having multiple Zulip realms open simultaneously
Build a slick development login page to simplify testing (similar to the development homepage on web) Improve the compose box to let you see what you’re replying to
- Make it easy to compose messages with mentions, emoji, etc.
- Display unread counts and improve navigation
Hide messages sent to muted topics
- Fill out documentation to make it easy to get started
Most of the projects listed under Android apply here as well, but it’s worth highlighting some areas where iOS is substantially behind Android. The top priority here is recruiting a lead developer for the iOS app. Once we have that resolved, we’ll expand our ambitions for the app with more specific improvements.
- Migrate platform from QT/webkit to Electron
- Desktop app doesn’t recover well from entering the wrong Zulip server
- Support having multiple Zulip realms open simultaneously
- Build an efficient process for testing and releasing new versions of the desktop apps
These don’t get GitHub issues since they’re not technical projects, but they are important goals for the project.
Setup a Zulip server for the Zulip development community
- Expand the number of core developers able to do code reviews
Expand the number of contributors regularly adding features to Zulip
- Have a successful summer with Zulip’s 3 GSOC students