Post

What prevents abuse? Maintainers of npmx are changing the data of their other projects, don't you see how this smells bad? Even if all is correct, relying on self-reporting means the incorrect data on other projects makes those look bad by comparison.

I’m fine with this as long as they publish who reported the anomaly and why. If it’s public it’s maybe more likey to be scrutinized. Also the ability to toggle between the sanitized and raw charts is reasonable. The question is, how maintainable is this?

One concern I have is, will people start to use this as a means of “explaining” or rationalizing downloads of projects. Who ends up invigilating what an “anomaly” is considered and could that extend to classifying fair or unfair downloads? Does this leave room for litigious banter. That’ll be tricky

My solution is: be very, very clear about how what this process is for (anomalies) to mitigate litigiousness. Setup an approval process that is bulletproof.

0 reposts3 likes

At minimum clear documentation and a definition of an anomaly needs to be written and clearly visible. A process for redacting or questioning recorded anomalies might be good. An official statement of who invigilates the submissions and accepts them. Perhaps two-party review mechanism. 👍

Without an official verified source, this seems to be the only way? Building the dataset and crowd sourcing it seems like a reasonable approach.

It's not reasonable for data to be skewed for some packages and not others. A user reading the pages isn't aware of the implementation details. But for this particular case, if there was a known issue with this date range, why not just exclude it from all packages?