Our team needs a robust issues system immediately, so we can get it in shape for a wide audience. Currently our issues are a mess across Discord, GitHub, and Hypermedia.
If our team is expected to be productive, we need an effective issue system now (or ideally, yesterday). We can't wait for months until the product is capable of acting as an issue system.
This is not to negate the value of dogfooding! We need to dogfood! But the product is designed for permanent knowledgebases, and is not yet capable of managing lists of issues. We have important knowledge to share: Guides for the app, tech specs for the protocol, and a high level introduction to Hypermedia. We should focus on those knowlegebases if we honestly expect our users to use the app for building knowledgebases.
If we try to abuse our documents product as an issues system, it encourages us to work on the wrong features and it risks our ability to make our product good for building knowledge communities.
I believe our issues system needs the following features, which are not present in the product:
Issues must be assignable
Our Hypermedia documents cannot be assigned to an arbitrary user. We have mentions but that is a different use case than assigning ownership.
We could build this into the product one day but we haven't discussed that yet.
It must be possible to file issues even if you don't have the app installed yet
Some people have trouble installing or using the app, and we still want to accept issues from them.
Copying issues into the app is not an acceptable solution, because we may need to interact with the user.
The solution would be to accept issues through a web interface.
Issues must be closable
When an issue is complete it must be easily marked as complete and disappear from the list of active issues.
We have talked about the ability to close documents so they are archived but no longer considered active. But we have not built this.
Issue owners and subscribers must be notified
We should notify the person who is responsible for fixing the issue (the owner of the task, not the person who filed the issue). And we should allow other people to subscribe to issues they care about.
The product does not have a notification system, and we want to build one, but other features have taken priority (for good reasons!).