Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transparency Log of Report Invalidations #52

Open
GalvinGao opened this issue Apr 27, 2022 · 0 comments
Open

Transparency Log of Report Invalidations #52

GalvinGao opened this issue Apr 27, 2022 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@GalvinGao
Copy link
Member

GalvinGao commented Apr 27, 2022

Due to various external or internal reasons, sometimes we need to do report invalidations or changes based on the issue lays on the dataset, for a more easy-to-interpret dataset there has. However, those changes are currently not transparent to the external users and even sometimes causing problems for ourselves to keep track of exact records in which have been edited. Therefore there's a proposed transparency log of changes made to the dataset, in an effort of keeping the track and to the community.

The log consists of several features:

  • A dashboard of on-going continuous automated invalidations. Currently, if the report is not meeting with the DropInfo defined in a specific stage, the report will be automatically flagged as non-reliable, effectively invalidating the record. Other than that, there's no other on-going continuous invalidations.
  • A list of instantaneous invalidations. Those typically consists of service abusing from a particular IP address or Account, as a huge number of their reports are statistically extremely unlikely to happen, in which we consider an abuse to the service and will flag those IP/Accounts manually. Such cases are currently relatively unlikely to happen, but we do have to intervene several times before to avoid huge deviation on the dataset.
  • A dataset snapshots of before & after invalidations are generated. This could be somewhat trivial to implement and its importance might not be so apparent. Open to discussion on this idea.
@GalvinGao GalvinGao added the enhancement New feature or request label Apr 27, 2022
@GalvinGao GalvinGao self-assigned this Apr 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant