Proposal: Decrease weight of memory function

[hstove]

What is the problem you are seeing? Please describe.
Right now, 45% of your current score is based off of your previous score. This may be too high, and it definitely makes it hard for apps to improve if they got a bad score in the past.

How is this problem misaligned with goals of app mining?
While we would like to have some stability, you should be able to be rewarded well if you provide dramatic improvements to your app.

What is the explicit recommendation you’re looking to propose?
Let's change the memory function to something more like 15% of your previous score, instead of the current 45%.

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.
This will provide more 'mobility' in the rankings - it's easier to go up or down in rank from month-to-month.

[kkomaz]

Yes and I believe this goes back on what apps should sign up for app mining. Should an app that is still in development without an MVP join? If so, then the early scores will significantly impact the latter as the app evolves.

Brings up another point of determining eligibility. If I'm not mistaken, apps that are applied to the google/apple store need to fit some type of criteria before being eligible. This would safeguard against the app owners themselves from potentially low early scores.

Just going to copy and paste what I wrote in #61

• Did I just ruin my overall app mining score by submitting too early? @xanbots // @pstan26
• Should the better approach have been WAITING until everything was flushed out? Will I always be fighting my way to the top carrying the burden of my negative early scores?
• If I had a choice between 87 cents + lower score vs. not submitting. I think you know the answer.

[friedger]

I am for this proposal because it makes app mining more fun and more clear that you should not rely on a steady income from app mining but also look for other funding.

I am against this proposal because development planning within monthly cycles is difficult.

[friedger]

As discussed with Jeremy, this is good because app mining should be about rewarding (hopefully positive) changes!

[kar2905]

I'm 100% for this. This will motivate apps to keep working hard to improve.

[cryptocracy]

Regarding decreasing of Weight of Memory function: I fully agree that the weight of the memory function needs drastically reduced. Cryptocracy has went down in ranking each month, even though we have continued to march ever closer to our MVP and have steadily added unique features that add utility to the ecosystem. The weight has such an impact that it would seem to inspired app developers to wait until MVP is done, before registering to avoid being punished for being reviewed while under active development.

[stackatron]

@hstove final answer? 15% 20% 25%? Think I'm worried about overcorrecting here but defer to you.

[avthars]

25% seems reasonable

[cryptocracy]

I am think 15% would be best, but that is just cuz I prefer less incumbency and more mobility.

[jackveiga]

I think @jeffdomke makes a good point, feels more reasonable to start with 25% and see what that results in.

[kkomaz]

I am leaning towards 15-20%. It really depends on how many apps are in significant development vs. MVP and currently participating in app ming.

[charlottelucyhall]

I think 25% would be good to test the waters! Agree 45% seems very high.

[friedger]

20% is a good compromise, I'd say for the next month

[GinaAbrams]

Leaning toward changing this to 25% for April. It is something we can continue to discuss, but I plan to close this out at end of week unless there are objections to that plan. 🙏

[kkomaz]

@GinaAbrams Is it moving forward 25% memory function or is it going to be applied prior as well?

[hstove]

We will only do 25% moving forward, because if we applied it retroactively it would effectively change the rankings for prior months.

[friedger]

But the ranking is not relevant here, just the numbers of the total score count. You can apply the new memory value on the old numbers and get the new total for this month.

[hstove]

You can apply the new memory value on the old numbers and get the new total for this month.

I understand that this is possible on a technical level, but it adds much more complication and room for error. I also understand that app developers don't want to be 'punished' for low scores, but once we switch to 25%, that old score only counts for an extremely low percentage of your new score after just 2-3 months.