If you follow us, you know we have been in full-on build mode. We are building, the community is building, it's great. Building is our daily business, so we think a lot about improving it.
Our most recent approach is to reduce the number of tools and platforms we use. Every tool you use
We thought about the platform/ tool we spend the most time on. Hardly surprising: it's GitHub. Not only do we spend a lot of time there, but we also WANT to spend a lot of time there because:
So far, we have been using Linear for our Backlog/ Task Management and synced issues we want to showcase or work on with the community via synclinear.com. Not only did we have our development issue there, but since
we have our own resident founding designer. We created a proper design backlog to structure our design workflows.
To achieve this, we created a few GitHub repositories to host issues, with the main repository remaining the central point of interest, especially for the community.
Apart from the source code of the Documenso app and platform, the main repo houses issues raised by the community and issues where we invite the community to participate.
While overhauling our issue management, we are also updating our progress communication. While the software and product development process is highly complex,
we try to give as much insight into what we do as possible. To that end, we went through 3 phases, three being what we do now.
1. **One extensive roadmap**: Initially we had one roadmap and were (very) slowly checking off boxes there (via a "Roadmap" milestone). While this is easy, it's also pretty imprecise and not practical as the project grows
2. **Estimated releases per quarter**: To give better guidance, we tried communicating our goals for the quarter, a pretty big window we thought we could roughly "hit". While the idea of not being too detailed was good, it is tough to estimate when some significant things are done if you do a lot of minor/ other things in parallel, e.g., working with the community and tuning things you go. Hitting time targets is tricky because there may be better ways to stick to that time target if other things arise. This is much easier to grasp for the people closely involved. The fallacy is to assume the thing you plan for exists in a vacuum.
3. Since we do not want to limit ourselves in choosing the most effective course but still give some insight into what's going on and what's coming up, we updated the LIVE Roadmap [https://documen.so/live](https://documen.so/live) to show what we are **currently working on and what's up next**, once we finish. We do not provide a specific timeline since we couldn't if we wanted to. Of course, we should set our short-term goals based on what's best for the community. We give updates on the issues being worked on as well as possible.
The public backlog houses everything we want to build eventually. We need to guide when that may be. We want to say that if we decide against something, it will be removed from the public backlog, as we consider this our long-term vision for Documenso. If you are interested in something on the roadmap, comment on the issue or post on Discord.
Issues in the public backlog are available to be worked on. For issues to work on, please check the main repository issues. The issues found here are scoped broader since they are not meant for immediate execution but rather give a sense of where Documenso is going and what we consider part of our Domain.
This is the actual replacement of our Linear backlog. Here, we host issues that are too small or short-term for the long-term roadmap and too niche or core to go into the main repo. We used a GitHub project as our development Kanban board.
This is the design equivalent of the internal backlog. The internal design backlog houses our design projects that include the exploration of new features, detailed UI designs, and improving the platform overall.
While the internal design backlog also existed in Linear, the public design repository is new. Since designing in the open is tricky, we opted to publish the detailed design artifacts with the corresponding feature instead.
We already have design.documenso.com housing our general design system. Here, we will publish the specifics of how we applied this to each feature. We will publish the first artifacts here soon, what may be in the cards can be found on the [LIVE Roadmap](https://documen.so/live).
If you have any questions or comments, please reach out on [Twitter / X](https://twitter.com/eltimuro) (DM open) or [Discord](https://documen.so/discord).
