Apps listed both in appfilter.xml and requests.txt about arcticons

[TotallyAvailable]

13494 Requested Apps Pending (Updated 15 October 2023)
17771 Requested Apps Pending (Updated 13 January 2024)

😱

[TotallyAvailable]

The next round of 266c144 should take care of those.
While there are quite a few duplicates and even a Loli Snatcher entry (https://github.com/Arcticons-Team/Arcticons/blob/main/App_Deny-List.md),
I do seem to remember noticing a few apps that have been covered for a while that are still there.
Might be something worth looking into regarding #1831 assuming the entries I'm thinking about are actually still there.
The most obvious one would've been 'mucke' but apparently me and my "cover by existing" never ended up covering the ".github" version...

I'm sure one of the script magicians around could tell us exactly how many entries there might be that shouldn't be there or if I'm just imagining things.

[alchemiker]

Hi @TotallyAvailable thank you very much for your answer! Do you mean that the list wasn't updated after the new version came out, or that there is a mistake?

Thanks for pointing out "mucke", I just created an icon for it yesterday (but didn't upload it so far...)
I will try to find out which script compares the entries from the requests.txt-file with the appfilter.xml-file and whether the results are reproducible for me.

If you have more examples of doubled app icons, please write them here, so others can test their bug fixes against the known duplicates.

EDIT: I looked up mucke and just added the intent filter with "github" to the appfilter.xml, so this should be fixed by the next round: 29da399
I'm not mad at the script that it didn't recognize that those two are the same because they have a different path (on the opposite I have already seen elsewhere two completely different apps with identical names, so that's probably desired behaviour), but in the WallFlow-Case the pathes are completely identical, so I think it's not intended behaviour.

[Kaiserdragon2]

From the looks of the commits the script isn't be executed since adding these icons this would explain why the still are there

[Donnnno]

Gotta run the script again, then those entries are removed :-)

[TotallyAvailable]

How about labeling the current request file "beyond saving" and while still updating it also putting new/updated requests into an actual manageable new file.
While that would end up creating a "priority request lite" initially, it would not only represent the current userbase more accurately but also allow for a more lightweight and somewhat focused handling of the actual (realistic) backlog.

[Donnnno]

I know that the current list is beyond saving, but I can't imagine how a “priority request light” system would work. Before the Play store releases, we used to do it with GitHub issues, but that was even worse 😅

[Donnnno]

The list has been updated just now :)

[TotallyAvailable]

The "priority request light/lite" was more of a "if we start a new list, any new request is now likely to be covered quickly" instead of sitting somewhere 20k lines deep in a text file like "normal" requests.

[Donnnno]

Ehh, I think the current popularity based system works the best. The file may be heavy, but that's just a downside to it.

[alchemiker]

Ehh, I think the current popularity based system works the best. The file may be heavy, but that's just a downside to it.

The thing is, that there are many "corpses" in the list. For example, when searching for the activity names of some popular games, I found many entries from a while ago, which were wished once or twice, which are called something slightly different yet similar to the original game, and are not to be found in any of the stores (anymore?). I suppose they were plagiated versions that were taken down quickly, but had their little boom and were installed by people. Also apps of companies that no longer exist, etc.

My heretic suggestion would be to kick out old entries. The oldest is from 1. April 2022. If a hard cut seems too harsh, we could make a shuffeled system: entries that were requested just once after half a year, entries that were wished twice after a year, entries that were wished three times after two years... you could then also allow for more requests per person, then you would get more accurate data about how often which apps are needed.

I will try to make some calculations to see what effect it would have on the volume. If we had a real data science pro at hand, we could calculate a rate of requests per month and the probability that the app was wished before, and based on this calculate ideal times and numbers of requests... a real-life modelling problem, my old math teacher would be so excited!

EDIT I ran a script: my proposed setup would delete per now 3829 entries that were wished just once, and 37 entries that were wished twice.