leoj3n
commented
4 years ago The more I look into the "Game Theory" aspect of this system, the more I realize normal people are not going to understand it, and the less that people understand it, the less people are going to trust it. Why not just present reviewers with two apps, and ask them which they think is better? That makes so much more sense without all the smoke and mirrors. It will be obvious when someone is cheating because we can all use common sense, which this "Game Theory" system cannot. It is obvious when an app is better than another, and only for a near tie might your number of social media followers matter, and even then we all know that is BS.
cuevasm
stackatron
njordhov
The "Formulas", "Game Theory", and walls of text explaining all that are all confusing and huge barriers to understanding what the heck "App Mining" really is in a short amount of time, unless you are already really passionate about it, which as a developer coming to the idea for the first time I really am not, I'm just interested in building great useful apps. So, that is to say I grok the general concept from the 50-word explanation, but then it gets super hairy and confusing. I know if I try harder I could understand what it is, but still not why it is that way without even more work.
Why not keep it simple and true to the idea, and put apps up against each other? That could be explained as simple as: A vs B recursively, until one comes out on top. I think that works out mathematically, while still remaining practical, but perhaps I am naive (let me know).
You could embody the personal biases of the reviewers into the score, which I think is the way it should be, as long as you are using humans to evaluate, instead of trying to turn those humans into robots that fit into a formula. For instance, if app A is more useful to the user and perhaps easier to use than app B, then let that come through in the fact that app A has a victory over app B. App B might still beat app D, which beat app C but also lost to app A. This gives app B incentive to become more useful and easier to use than app A next round (while also continuing to try and be better than app D), thus encouraging continuous improvement.
This measurable goal of improvement I think should replace the current focus on being first to submit a new app, at least those "make a new app and submit before deadline to get the bonus" types of incentives tend to stress me out. I get the desire to entice new app developers (or just new apps) to join the fray, but I think you might have just as much success promoting the rewards you get from constant development, which is less ostracizing and less one-off. This is just my opinion on the hackathon reward structure, which I think would such restructuring might be more in line with the goals of the App Mining program (thus helping demystify the program to begin with).
So, the idea is to pit apps against each other, A vs B vs C vs D, where there are winners and losers based on direct comparison. Perhaps to limit the sheer number of comparisons needed to create the chain of winners, structure it like a tennis tournament where there are consolation rounds, to limit the breadth of "matches" needed.
I have very little knowledge of the history of the App Mining program, and don't have much of an opinion about it, all I know is I was introduced to it via hackathon and now am part of it. In trying to understand it I found it to be overly complex and wish it worked more simply like the way I'm explaining it here. I understand more embedded people may have ideas on why this suggestion might not work, which of course you should share in response.