Top 15 Voting -- Features & Fixes Wishlist + Community Kanban Boards

:apple::bug: Bug Prevalence :bar_chart: Vote for Fixes & Features

Our objective is to measure the amount of individuals impacted by each bug in Anytype, but also to help us to prioritize development, optimization and fixes that are most urgent within the current time-frame.

To conduct this appraisal we’ve utilized Voting, visible to the left of every topic’s header in the Feature Request and Bug Report categories.

  • You have 15 Votes at your disposal, of which 1 can be cast per Topic. Cast them for the Bugs that are most the inconvenient for you, or for the Features which you desire most.

  • Votes cast for Feature Requests will be tallied separately from Bug Reports, but generally, Topics which accumulate the most votes will be treated with higher priority.

  • In the categories where voting is enabled, “Likes” :hearts: can only be given for comments, to avoid conflating the results of Topic Voting.

  • When a Feature or Fix has been implemented (and a Topic is closed), your votes will be released to you again.

  • Don’t waste your votes! Please refrain from voting for topics which don’t require it. If your votes are depleted, comment instead and add your vote later.

Note: Vote limits cannot be customized per category. There needs to be a feasible limit to retain their value and to assess the results of the votes in a comprehensible way. The more votes permitted, the more diluted that assessment becomes, this is the reason voting is limited to your Top 15 wishlist.

For inspiration :point_down:

Top Feature Requests

:newspaper: Other News

Community Kanban Boards :white_check_mark:

Development Status of Feature Requests and Bugs Reports categories, can now be observed as a Kanban View!

Storage Rewards Clarified We want to give an extended storage reward to our Alpha types who contributed here in the Community. For those who didn’t and miss this info, using Anytype for free is already it’s own reward.
  • Members who migrate from Alpha to Beta will automatically receive Alpha rewards

  • The option to “Get More Space” is only displayed when you exceed 1GB capacity.

For those eligible for rewards: there are multiple ways to confirm one’s participation in the Alpha program

  • Whoever joined the Community prior to Beta is already an Alpha Type (anyone who joining after is a Beta Types)
  • We also have a CRM of all the Alpha invite codes ever sent (we do not use this for any purpose other than to (re)send invite codes).
  • Alpha Types who start fresh in Beta should:
  1. note their Alpha Anytype ID ((or their Alpha Type forum-name)
  2. click the “request extended storage” button inside the Beta app
  3. send info along with their message

For all other Storage Upgrade Requests:
We don’t charge anything for backup storage at the moment, and we’d be thrilled to upgrade your limit for free! All we request is a brief 30-minute chat about your experience with Anytype.

Simply click “Get more Space” (in Settings), once your storage is at full capacity. We’ll send you a link to book a chat with our Product Manager.

Important Notes:

  • Remote Storage only applies to files (ie. .pdf, .jpg, .mp3, etc) stored on the encrypted back-up node, which is accessible remotely via our Anysync feature (Objects do not consume remote storage).
  • You can store as much as you want on your own device, since Anytype is local-first. Which files are stored and the amount of remote storage consumed / remaining, will be indicated by a bar graph in your settings.
  • Alpha Types are eligible for 10GB of remote storage for their long-time support and contribution to Anytype (include your Community name or Alpha AnyID with your in-app request. There is a limited amount of time for which this reward can be claimed).
  • Beta Types will receive 1GB of remote storage for free
  • In the future, we will employ a system of points, which can be accumulated and redeemed in various ways (the precise details of this are yet to be fully established).

What is the deadline to claim the increased storage for alpha types? As you said, if we start fresh, we’ll only get the option to request it once we reach the 1GB capacity, is there a way we can request it ahead of time to secure the 10GB storage?



Some months

Will there be any way to request it before we get the 1GB capacity? I want to start fresh so I’m afraid I might not get the pop up within the time frame, and I don’t want to just fill up to get the 1GB capacity since I don’t fully understand how anytype stores, and don’t want to make things messy.



This is how it works for now. When you request extra storage it will send it to our support directly from the app, just include your Alpha Type (sooyoung) name along with your message.


Alright, hopefully I’ll be able to claim it before the time is up.

Will there be a notice before the deadline, since there doesn’t seem to be a clear deadline set yet?


Hello, I’m one of the Nightly Type users, and my Anytype client has been updated to the beta version functionally today. However, I noticed that the storage limit is still 1GB, and my community type has been changed to beta type. I would like to know if this change means anything and what happend.

1 Like

I would also like to know. I am nightly type ( previously alpha type). I am also seeing 1 GB limit.

1 Like

@1294640532 @vanish your Nightly Type accounts will adjusted automatically.


this one gets asked a few time. But the AnyType guys can easily see if you are part of the Alpha group. Additionally, if you go to your account profile, the click preferences, you can see your ‘title’ and ‘flair’. You’ll see you have AlphaType and NightlyType as options there.

thanks a lot, it has been updated :grinning:

1 Like

Although very late in coming, the rationed voting system is very welcome. But why did you activate this voting option for bug reports?

Firstly, by definition, a vote is something you want, something you act for. You shouldn’t vote for a bug, because the purpose of a bug is not to be wished for, but to be fixed.
Furthermore, these votes would have no value since the bugs are already shared by everyone, so everyone equally wants to see them solved.

Secondly, this would even prove problematic, because if we rely on the voting system to reflect the impact of some bugs, this attempt will often be prevented by the same voting system, let me explain:
Members who have already distributed their 10 votes will find themselves frustrated by not being able to vote for a very critical or annoying bug, and will only be able to do so by searching their personal profile for the votes they have previously allocated. On top of this, they will have to resign themselves to removing one of them. I don’t think that’s wise.

I really don’t understand this choice. Could you enlighten us?


This could easily be applied to feature requests as well.

The point of the votes is for the devs to check which bugs and features they should prioritize first. They can’t work on all the bugs / features at the same time.


I don’t think so, for one simple reason: people like to dream. I doubt very much that anyone would prioritize all their votes on Bug reports alone. Whereas the reverse is far more likely.

Feature requests, however much they may be desired, are merely improvements, whereas bugs, depending on their impact, are problematic or even disabling to the point of preventing the use of a function. In this respect, I think reliability prevails over idealization.

In other words, this common voting quota seems deleterious to me.

Thanks for pointing out the obvious, but I’d already grasped it. :smile:

1 Like

Then don’t vote for bugs fixes…simple as that.

Exactly, you’re voting for where you’d prefer the devs devote their attention in the most current time-frame, since not everyone is affected (or bothered) to the same degree by a given bug. It may not impose on ones work-flow, or even manifest at all.

The devs will not ignore any bugs, they are always a high priority and in general, issues are resolved pretty quickly. It can happen though, that they are more focused on building features, and votes help us to keep our finger on the pulse of the community.

It’s merely a way for members to express their utmost wishes for the app at that moment. When the issue is closed and that vote returns to you, apply it to the next most important thing for you.

This point further supports why voting for fixes should also be a measurable factor in the communities collective will.

The devs have limited bandwidth, and if features are prioritized the most, then some bug fixes can get put on the back-burner. If they can only fix 5-10 bugs a day, which of the 1,000 bug reports should they focus on that day?

Voting for dev priority is a means for people to direct their desires for the app where ever they see fit.

Additionally, a suitable number of votes are provided per person to compensate for any quandary like you’re imagining, to grant sufficient leverage in either category.

Finally, you can also just communicate under the topic. Words have sway as well, and nothing is preventing you from voicing your opinion :wink:


I forgot to mention that you can indeed just comment under a post, and usually a dev will respond on the status of the bug / feature.


Thank you for these detailed explanations. Your arguments and your point of view are very well understood.
Like you, I see the advantage of prioritizing bugs, but I’m still convinced that there’s a benefit in dissociating the two.

I was thinking more of a system like :
5 Votes for Feature Requests.
5 Warnings for Bug Reports.

I suppose time will tell if this approach is necessary or not. :wink:


If I remember correctly, alpha and beta types get 10 votes in total, so there is nothing stopping you from using it that way already, right?

1 Like

You’re right, but I was thinking about the system as a whole rather than just my personal use of it.

1 Like