-
Notifications
You must be signed in to change notification settings - Fork 3
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
Feedback Loop for Accepting Store Data #473
Comments
I think this is the right way to go. We actually want to fix the data upstream. The cities need to have an up-to-date information about this.
I think this is a really good feature and maybe one of the first to do because it is simple. I think we will find a way to present the data to the user without confusion. For example by hiding this information and only showing it with an additional tap. Like a "Mehr Informationen" on the bottom of the page.
Good idea for a future Bundesland!
I think this is a very difficult challenge. Right now we throw our complete DB away every week. If we want to persist data in the DB which is linked to any Akzeptanzstelle, then we somehow need a duplicate matching. Actually another way would be not to persist anything in our DB related to recommendations/changes. We could just calculate every months suggestions and send them out to the cities. Then we wait until they fix it. (The Google Search Console Way) |
Should be split into 5 User Stories:
Last but not least: We should not overengineer this :D |
Why "high priority": I think some of these tasks definitely have the potential to give insights about why data could be wrong. It could also help to boos the quality. I think this is less important than the Whitelabeling right now, but definitely worth it. |
I don't think this should be high prio right now. Data quality assurance should be done by regions / freinet / LBE themselves. |
mapping task store to regions is here #538 |
By now, we have the possibility to assign each accepting store a landkreis/stadt that is responsible for that entry.
This enables us to create a feedback loop to enhance the data source of accepting stores.
This issue is rather a brain storming of ideas we could implement (and we should probably not realize all ideas).
As a requirement we need to
p_eak_agentur_id
andanbieter_name
in the LBE XML.Once this is set up, we can do the following things:
Optionally, we can think about not to apply the sanitization on our end, but let the corresponding landkreis/stadt take this responsibility in the data source. That way, we would never automagically sanitize data in a possibly wrong way, but we would have some human™ to check whether our suggested change makes sense (and that human is not us, but the person creating the problematic entry).
The text was updated successfully, but these errors were encountered: