Proposal for Improving App Mining by Adding App Category Context

[cryptocracy]

What is the problem you are seeing?
Lack of app category context being taken into consideration by algo.

How is this problem misaligned with goals of app mining?
Lack of app categories seems to discourage new developers from attempting to tackle the more intricate or more complex applications that add diversity and utility to the ecosystem. For example, why would a new app developer try to compete with a simple app that has very little learning curve? When the new developer knows they will still be graded so to speak against apps that have a nearly non-existent learning curve?

What is the explicit recommendation you’re looking to propose?

1. Introduction of app categories that the app developer chooses from a predetermined list of categories when registering their app into the app mining rewards program that is derived from the app.co categories.

2. Require TMUI test users who do the actual voting/scoring to be categorically assigned and aligned to test apps that are of the appropriate target demographic of the apps category. (and possibly other reviewers)

3. Restructure Payouts: Since there is already 14 categories (per app.co currently)
   We could divide the 100k USD worth of BTC by the 14 categories, then divvy the pot per category out by a multiple that is .5 (perhaps even have the multiplier slide as we scale up to 1 million payouts)

Here is a gif that shows how a couple categories, and what the top 10 ranked apps payout structure could look like (bare in mind the multiplier doesn't change in this gif just the total pot size to give a sense of how payouts would look at 100k and how they would look at 1million)

Describe your long term considerations in proposing this change. Please include the ways you can predict this recommendation could go wrong and possible ways mitigate.
Potential problems would be too many categories, might result in spreading rewards out too thin.

Additional context
Doing testing according to a loosely targeted user base demographic by app category should also help avoid a echo chamber of apps in the ecosystem and by extension should inspire more diversity and utility. Since If the rewards are by in large only going to blogging apps or note taking apps, then we will wind up have a disproportional amount of app developers chasing the same type of app. (since thats the type of app that tends to be favored by users who participate in app mining)

Note about scaling up: Based on current exchange rates, if things were scaled for payouts of top 6 apps per category while at 100k total pot, then to top 10 apps per category when at 1 million total pot.
We would go from 84 total apps getting paid a min of $111.61 USD to max of $3.5k USD. To top 140 apps getting paid at least a min of $69.75 USD to a max of $35.7k USD.

[cryptocracy]

Obviously the rewards of app mining should not be the developers underlying motives, for them to start building apps, but rather bringing it to an MVP status to be self sustaining (and in turn bringing value to the ecosystem).
However, app mining is most definitely a form of incentive for on boarding, thus in my opinion, we should do everything we can to help foster as many high quality apps as we can get by rewarding as many apps developers as possible with as much as possible.

[dantrevino]

While I agree we need categories to help focus TryMyUI reviews, my concern is that, in terms of payouts, it shifts the concern from 'Why is my app valued the way it is?' to 'Why is my app category valued the way it is?'

[stackatron]

Thanks for adding this. I think this has merit and will likely happen at some point. Some operational challenges I predict:

• Who will arbitrate the categories? A new app reviewer? Whatever entity this is would probably need to contend with non-stop complaints re category decisions. Who would we trust to handle this?

• What happens when apps occupy multiple categories? Or want to migrate from a high-competition category to a low-competition category for obvious reasons?

[cryptocracy]

it shifts the concern from 'Why is my app valued the way it is?' to 'Why is my app category valued the way it is?'

@dantrevino ... I understand what you you mean, but I disagree, simply because, if the categories are equal total pot per, then favoritism couldn't be claimed as there is no clear preference of category.
And in the event of any insistence of one app category being claimed to be of a higher value then the others, the claimer should be met with a rebuttal that exposes how it is impossible for any one individual or small group of individuals to determine what the actual masses deem as valuable without significant amounts of analytics and data to back up the claim.
I think in essence we should not be trying to put the cart before the horse here. The objective currently should be to on board developers of all shapes and sizes so to speak, instead of trying to lump everyone into one basket that winds up creating more noise then signal.

[cryptocracy]

@jeffdomke ...

• Who will arbitrate the categories? A new app reviewer? Whatever entity this is would probably need to contend with non-stop complaints re category decisions. Who would we trust to handle this?

Couldn't we just have the developer set their app category the app manifest.json as well as specify the category they will start out in at start of their registration.
Then the lead up time, just prior to the app mining round starting, a snap shot of the app categories, as specified in the apps manifest.json, are taken, to ensure the appropriate testers are testing and to ensure they are part of the appropriate payout category.

• What happens when apps occupy multiple categories?

Good question, but the simplistic solution would be obviously to just limit to a single primary choice only for quality assurance purposes.

• What happens when the app want to migrate from a high-competition category to a low-competition category for obvious reasons?

If snap shot step happens of manifest.json to determine category prior to round starting, then in my opinion if the dev thinks it s a better fit, then why try to prevent that. If they are simply trying to game the system cuz that category is low quantity, then they should still rank near the bottom of that category because ideally testers scores would have a decent amount of weight associated to a question about if the app seems like a good fit in that category or not.

[GinaAbrams]

@hstove to add more context here.

[hstove]

I am not against the idea of having categories to get better TryMyUI testers. However, I still think that doing payouts by category is not a good idea. It is easy to see the list of apps per category before this 'snapshot' could be done. It would be trivial to look at all the apps in each category, and determine which category you could shoehorn your app into such that you rank higher than all of them.

Moreover, I think that this is not a good idea on an even more fundamental level. I do want to encourage innovation, but I don't think payouts by category helps that. Moreover, I don't think that it's a bad thing if multiple of the top apps are competing with each other in the same 'category'. It is certainly possible that some categories will find more success in the decentralized space, and we shouldn't hinder that. Also, competition is good for innovation.

[stackatron]

We discussed this internally and concluded that this makes sense with 100s of apps and well over $100K in payouts and we will reconsider this when those happen.