We need improvements to the current bug and issue tracker

Is your feature request related to a problem? Please describe.
Looking at the Feature Requests and Bug Reports sections of the current forum, I (and I’m sure, many others) get overwhelmed with the lack of organization within it. There are multiple duplicate issues, solved issues are mingled in with the unsolved issues, and often, the reporter forgets to mark the issue as “Solved”, even after it has been resolved.

Furthermore, the lack of transparency is somewhat frustrating; we often have to either look at the Roadmap or the comments one of the team members have left in the thread to see if this issue or request is being taken seriously, or has lower priority.

Describe the solution you’d like
If the current forum system for issue tracking is going to be kept until the project is open-sourced, it’ll be a good idea to invest some resources into keeping it organized and well maintained.

To help resolve the issues with numerous duplicate requests, being able to add an “Duplicate” tag would be useful. The duplicate issue can then be hidden in a subcategory (e.g like the Release Notes inside Announcement category), and if the duplicate issue report is detailed enough to merit being merged into the existing thread, a staff member can do so.

Moving “Solved” threads into its own subcategory, just like what I’ve proposed in my above proposal, would also be great for improving sorting.

I also believe we need to rethink the way in which we “close” an issue. At this moment, the only method we have for indicating an issue no longer requires attention is for the original poster to mark a specific reply as “Solved”. This causes numerous problems; for example, we’ll probably want to close duplicate or spam reports, but marking them as “Solved” would not make much sense. Furthermore, as the original poster is the only user allowed to close the report aside from forum moderators, many issues that are solved pile up, either due to the original poster forgetting to close or the moderators not doing so.

Therefore, we need a more robust system for marking an issue as no longer requiring attention than a simple “Solved” checkbox. I believe the forum should adopt a GitHub-style “Closed” or “Open” status tag for all issues, where we don’t need to pick a specific reply that “solved” the issue, but just close and open based on whether it is relevant or not.

The forum should also partition the “Solved/Closed” issues into its own subcategory, so the main category is not littered with issues that don’t require attention.

With the lack of transparency problem I’ve brought up, perhaps assigning a priority rating/tag between 1 (for most urgent) and 5 (for least) would be valuable for forum members to determine how quickly an issue will be solved may be helpful. If resources and time allow, the developers might also want to consider signalling their progress on the issue with tags, such as (“In Roadmap”, “Investigating”, “Working On”, “Won’t Fix”).

I’ve also noticed that many bug reports have replies by staff members stating that they’ve added it [the bug report] to the issue tracker, like in this post. I’m somewhat curious about this; is this bug tracker different from the bug tracker in the forum? Is there a reason (perhaps clutter or security) to keep two separate bug trackers?

I’d really appreciate some input into why there are two separate bug trackers in the forum by one of the team members. In my view, I’d think that having one centralized place to track all bugs and feature requests would be best for efficiency - especially if the forum’s bug tracker is improved and better organized. If merging the two are not possible or takes too much time, would making the “internal” bug tracker publicly viewable (but not editable) for beta testers be an option?

The last proposal concerns the organization issues I’ve mentioned before - who should be allowed to close issues and assifn “Duplicate” tags, if they are implemented? Clearly, the team’s time is much better spent on development and investigating bugs than manually dealing and sorting each individual bug report.

I believe that editing such tags should be as accessible to as many forum members as possible. I’m thinking that users who have attained a Discourse Trust Level of 2 should be allowed to edit posts; it appears that most isers are at this level.

Yet, allowing users to edit and self-moderate the forum will inevitably cause conflicts, disagreements and fights. So far from what I’ve seen, the vast majority of posters here are respectful, considerate, and have avoided using harsh language, but that is not a given. I don’t have a great proposal for a solution to this issue, but perhaps something can be figured out.

Describe alternatives you’ve considered
It is possible for individual users to improve post organization using filtering options available at the top of each category page. However, this is only transient - it appears to be cleared upon next visit, and may not come easily to newcomers.

Additional context
This long post was written out hastily, and I haven’t had the time to throughly dissect and think carefully about every proposal I’ve made here. Therefore, there may be grammatical errors, nonsensical writing, and flaws with the individual proposals I’ve made. Please point them out if you see any - criticism always leads to improvement!

Furthermore, I recognize that this is a very long post filled with many requests. Please keep in mind that they are requests, not demands - many ideas may not be great, and under no circumstances does the team have to implement them if they don’t wish to.


I agree with almost all requests!

The transparency is, what for me is very missing since a few months.
If the team doesnt have enough time to fit all those requests, I can understand that good. In this case Ill propose the mentioned solution of making the teams kanban publically available. Or implement a bridge, like a public trello , where requests go, and are moved when status changes.

This would clarify much! Thanks in advance @team


Like this one: Release plan - A general roadmap UPDATED: 11 Jan 2022 zn kanban format and extend and kept uptodate.

If something gets approval on telegram, would be nice if added here, or in the new kanban view in a not too long time span :slight_smile:


It’s great to hear that I wasn’t alone in thinking that transparency was a bit lacking with the current system - it really did feel like I (and many other forum posters) were shouting into the void, with little to show for it. I totally understand the developers are working hard on the software, but, I’d appreciate having more transparency.

Personally, I think that having one centralized place to view and track feature requests and bug reports is more favorable than having multiple places (in this case, the public forum, “Release Plan” post, private bug tracker, and the Trello). I hope my proposals for improving the forum’s issue reporting and management can help fulfill this goal, but my worries are that having a Trello might cause the same issues we have with the “Release plan” roadmap post - it might be infrequently updated and only contain major features, due to the board being time consuming to maintain.

Either ways, having any of the ideas that were mentioned in your post would go a long way towards improving transparency; it’d be better than what we have right now.

@edwards hey! Thank you, you raised a very important theme.
First of all, we read all the input from here! So every single bug or feature request is received by recipient (us :slight_smile:). Secondly, we are definitely losing momentum in community management and will fix this in the upcoming months. We’ll have an internal discussion and get back here with a plan!


Sounds great! It looks like for many of the major note/productivity apps, notably Obsidian, Roam, Notion and GoodNotes, the communities surrounding them are one of the reasons, if not the primary reason for their success. I often see various forums, Twitter accounts and subreddits - both official and unofficial, filled with passionate users who are sharing their creations and discussing the product. It would be essential for Anytype to capture the same sense of community and belonging in order to be successful. Having a functional and streamlined issue reporting process is also very important during this stage of Anytype’s development - the primary target for my improvement suggestions. Please keep us posted on the updates regarding community building and issue reporting!


I’m happy this was brought up. I only recently joined Anytype and have had some trouble getting an overview of how far all the work-in-progress features/bugs are. Finding a roadmap or list of current issues was more work than I was hoping and I’m still not sure if the Release Plan mentioned above can be considered an official list.

A full-on Kanban board of everything would be great to put some structure into the growing list of posts - but in IMHO it can wait a little if it saves time in other areas. An overview-like list (like the Release Plan) with some checkboxes and approximate release dates would add a lot of valuable insight and would be quite motivating for continuously testing the newly implemented things.

I have full understanding for the amount of other stuff going on the internal dev side at the moment - thank you and please keep going! :muscle: I’ll be looking forward to the coming updates.


+1 on public kanban. will be great to see what is actively been worked on and what has formally been captured on the enhancement or bug/issue list

And also completely appreciate with the amount of work that needs to go on to both develop and comment/read/review/manage the forums and posts. I do not underestimate this at all.

I think in relation to the comparison to Obsidian/Notion etc and their communities - we need to bear in mind that Anytype is still only in Alpha. and even then, only a select few users - so bearing that in mind, and the fact that there is still this much activity amongst the community members is amazing! So can only think that once it goes into public beta there should be a greater expansion of the community. :crossed_fingers:


I completely agree that the community management and bugg / feature tracking could be better.


  1. Better bug and feature trackers
  2. Easier to read and use roadmap for upcoming features
  3. Bigger, more public community including youtubers/tips and tricks

ObsidianMD has a simple kanban board as the roadmap stating what is finished, done (for the next big release), Working on and what is on the short and long term radar. All without specific release dates because that will not work and gives more issues then benefits!

I had a bugg report removed (including an auto message stating I should read and follow the forum guidelines) because it was a double post where I searched before reporting this bugg and didn’t found anything related.
That was a bit disheartning since I put effort into the bug report (or any post) just for it to be removed like that hehe.

Also, as I asked a long time ago if there where any youtubers or resources to get inspired, tips and tricks because that will boost the community greatly (it’s why Notion became so big, so fast). While there is no real NDA it is prefered to not publicly post videos since it’s still such an early alpha and not the final product.

These are in my opinion the three things that will boost the community and anytype to new heights (including the great updates and features)


Hey! I’m very sorry about that. Was it Closing the app only hides the foreground app - #5 by Jeroen? Looks like your post was merged with the same problem and the notification you got as “Flagged post removed by staff” was wrong. All your efforts still exist on the forum! We will change the notification to make it related to action and more friendly


is there something new on this? Are there ideas or plans by the team already?


This is taking place in next few days

Will there be writeup or similar for people who cant attend?

Adding onto that, I’d love it if those who may be unable to attend the community session due to time zone issues or scheduling conflicts could submit a few questions to be answered during the meeting.

God no, please not another privacy-nightmare. AnyType is already using enough non open source stuff when there are free alternatives.

If the team is willing to switch to GitLab it would be possible to show issues in a Kanban view and move them around and auto-assign tags. Its possible (afaik) to set templates, one for feature requests and one for bugs. And iif you move on the Kanban view the issue gets updated and the other way around the same.

I mean, ideally, for the Roadmap there would be an AnyType-Kanban-Board screenshot. “Backlog | Planned | Developing | Finished | Archive” Kinda like this. And i don’t see what the problem would be if there is somebody enthusiastic enough to make videos.

A way bigger problem is the website in my opinion, btw.

1 Like

Thanks everyone for your feedback, and apologies for taking a while to respond more fully. :pray: We certainly agree that some improvements are needed! We have discussed all this internally for the last couple of weeks and we will definitely make some changes in the short and medium-term.

The forum is a fantastic source of feedback, but quite honestly the amount of posting here has become hard for the team to keep up with given current current staff and approaches. Processes are definitely being adjusted internally to make this all work more smoothly. There were various other circumstances in 2021 that contributed further to the challenges in keeping up on things (multiple team members got COVID for example! :grimacing:), but ongoing hiring and internal workflow improvements should make this better moving forward.

We are going to take this in stages. Our first focus will be cleaning up the forum content so it is easier for everyone to find, upvote, and contribute in general, while avoiding duplicates. And we’ll be putting more systems and roles in place to hopefully keep things tidy. After that we will work to improve the communication of internal development priorities to the community. We may or may not have a public Kanban of some kind (if so, it would probably be self-hosted, not using Trello, etc), but the forum will likely remain the primary way to provide feedback to the team, see what is being worked on, and what the community most values (top liked posts).

There are some other desires expressed here around tutorial content, empowering content developers, etc. and I’m not going to address those in full at the moment. For now just know that the team is very much aware of these needs, and the team itself is working to expand the native documentation as much as possible over time. Plans are being made for how to support the community in developing and sharing their own content to help and work with others, it’s just not quite time for that yet. But it will definitely happen!

For now, you can expect to see some content cleanup happening here very soon. And there will also be more news on forum organization and moderation in the very near future. Thanks again for your patience and participation in the Alpha program!


Any updates on this? It’s been a while.


True! Things have been happening behind the scenes, though a little slower than I hoped. But an announcement should be coming within a day or two that will lay out where we’re at and the next steps being taken. :slight_smile:


I hate to be a pain in the ass, but the one to two days are now approaching a week, and we are still left with zero updates on the matter.


I’m very sorry for not updating as I promised. I had intended to reply here on Tuesday or Wednesday, but then my grandmother fell quite ill and passed away just this morning. So I had to put a pause on this work for a bit.

I plan to make some more formal and detailed announcements in the coming week(s), but I’ll summarize where we’re at for now, what steps we have taken and will be taking, etc. Hopefully it will give you some peace of mind that we’re heading in the right direction.

Creation of Moderator Team and Improving Forum Organization

The first major step we are taking is creating a moderator team. We have several mods onboarded already (shout out to @AyneHancer and @Flip !), who are beginning to help out in doing things like merging duplicate threads, Closing/Solving topics where appropriate, fixing (adding/removing) tags, etc. We plan to settle on an initial group of 5-6 active and enthusiastic members of the community and we believe that together they will be able to lend significant help to the Anytype team to catch up and then keep on top of some of the basic maintenance here. More details on all of this will be coming quite soon.

Estimated completion: in progress, completion of onboarding and training within ~1 week. Completion of “clean up” phase estimated within ~30 days from then.

Feature Voting

Next, we are going to implement a new way to vote on feature requests! Although the Anytype team has gathered a lot of useful feedback via the existing “heart”/“like” buttons, there are various issues with its use for feature voting. I’ll elaborate on that later in a more formal announcement, but to put it briefly, there will be a new way to Vote, it will work with the existing “Like” system, and will allow you to clearly express “strong” support for a more limited set of features that are most important to you (for example your top 10-20 feature request priorities). This will provide numerous advantages and make real, current priority of the community more clear to the dev team. It will also let you see much more easily what the community thinks is most important as there will be a dedicated view by votes to show what has the most. Again, details will be coming in the future

Estimated completion: within 4-6 weeks

Development Status, Kanban, etc.

We are still working on how best to keep the community updated on the current status of development, but we agree that more openness is an important goal. So this section will be a bit more unclear as it is still in flux. But it is definitely being worked on.

The primary challenge is that updating every feature request or bug report that relates to a current development plan would require some involvement of the dev team, and this takes time away from development itself. We’re working on internal mechanisms to more quickly and easily communicate enough information without it becoming burdensome and slowing things down.

Whatever the specifics of the process end up being, there are a few goals being pursued, which we hope to achieve to at least some reasonable degree. But please keep in mind it will be a work in progress for some time. Also remember that all priorities and development communication are subject to change for a variety of reasons (blocking issues in the dev process, emergency fixes, team member illness, etc, etc.). The major goals include:

  1. Show general priority of major features (both those that reflect feature requests in the forums, and those that are independently determined by the team), and better reflect what the upcoming releases are planned to include
  2. Do a better job of distinguishing between new issue reports (not seen by the team), things seen and acknowledged by the team, and ultimately things in development and completed. Most likely Tags will be used for this.
  3. Ultimately it is hoped that when an existing Feature Request starts development internally, that status can be reflected clearly in the forums in a timely fashion (e.g. within 4-5 days of the status change)

Estimated completion: ongoing, initial milestones for improvement within 3-4 weeks, long-term overhaul within 2-4 months


Depending on how well the team is able to accomplish those goals while keeping staff time commitment to a sustainable level, then it is hoped to implement a Kanban view that shows the current dev status in a more clear, visual way. This is a definite possibility within Discourse (the forum software), and would work with a well-managed Tag setup, but it relies on effective, sustainable communication of internal dev priorities into the forum, and that’s the primary issue we’re working to solve first.

Why is this so hard?

As someone who has been on the outside of this process and wondered why it might be so challenging to simply show what people are working on, I understand if this seems a little frustrating or mysterious to you. That said, I have also worked in or with numerous software companies at various stages, from startup to 20-year product longevity, and in almost every case this was a challenging issue in some way or another. Whether that was due in part to a desire to maintain competitive advantage (which at this stage Anytype does still have a need for), or simply the time it takes to translate development tasks into something more easily understood. It just takes more time than you might think to effectively, accurately, consistently communicate what’s going on to anyone who is not directly part of the dev process and so does not have the benefit of that context and expertise. But the team will do their very best to overcome this challenge in the short-to-medium-term!

What about open source, etc? Won’t that fix this?

In the long-term of course Anytype will be open source, and much more. At that point things will be more open, but I think it’s important to make the point that even then someone (or multiple people) will need to make special effort and take time to make the current development priorities, plans, etc. clear to non-developers.

For example, let’s assume Anytype is going to use some public, open source repository like Github. In theory you should be able to go there and see what the current status is, right? Well, here’s what the Pull Requests for the open source project Discourse (this forum software) look like:


I don’t know about you, but that doesn’t easily translate to a clear list of features and benefits to me, as a Discourse user or admin. Looking at the Branches, Actions, or Insights is similarly “noisy” and unclear. Because of that fact, one of their team members takes the time to update a topic in their forums manually to reflect the inclusion of different changes for each major release:

But note that, depending on the time frame, there may be several updates in a month, or only 1 or even less in a 30 day period. You’ll find similar realities reflected in many, major open source projects. The information on what is being worked on is out there and available (for example in pulls and merges, etc), but actually understanding it often takes some expertise, and for that to become information that less expert people can understand it means some expert needs to take time to translate it, over and over again as often as updates are desired/needed/sustainable.

So hopefully this just demonstrates that, even if the team were willing and able to completely open up their internal task tracker, it would probably not provide the view of how things are going and what to expect that everyone wants to see. Being on the inside I see how difficult it can be for a non-dev to really understand what is going on, and how often plans have to change. To some degree there are significant downsides to seeing the every day changes. :smile: In any case the journey to better information being available and more regularly updated is in progress, but will probably never be truly complete. Team Anytype team will always be striving to do better though. :slight_smile: