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ā 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.
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:
note their Alpha Anytype ID ((or their Alpha Type forum-name)
click the ārequest extended storageā button inside the Beta app
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?
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.
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.
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.
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.
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
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.
and 5 Warnings for Bug Reports.
I suppose time will tell if this approach is necessary or not.
Bug Prevalence 
Vote for Fixes & Features
can only be given for comments, to avoid conflating the results of Topic Voting.
Other News
