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

Feedback Loop for Accepting Store Data #473

Open
michael-markl opened this issue Jan 25, 2022 · 5 comments
Open

Feedback Loop for Accepting Store Data #473

michael-markl opened this issue Jan 25, 2022 · 5 comments
Labels
discussion-needed We need to resolve the questions in the issue. user story

Comments

@michael-markl
Copy link
Member

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

  • Parse the newly added fields p_eak_agentur_id and anbieter_name in the LBE XML.
  • Find contact mail addresses for each landkreis/stadt (e.g. via freineit / manual search) and add them to our DB

Once this is set up, we can do the following things:

  • We can use our sanitizations as "warnings + suggested auto-correction" and send all these warnings out to the corresponding landkreis/stadt and ask them to fix their data entry in their source and add a contact address in case a warning is a false positive.
    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).
  • We can add the landkreis/stadt responsible for an accepting store to the details page of the accepting store. However, we have to check whether this is rather a confusion than a helpful information to the user: There might be an accepting store with a location that differs from the landkreis/stadt, e.g. an accepting store in Pfersee managed by the Stadt Augsburg => confusion of address. Probably, this confusion can be dismissed by an appropriate wording and layout, for example some small-font sentence "Die Stadt Augsburg ist für diesen Eintrag veranwortlich." below the other store details.
  • Add a feedback form to the details page of an accepting store. If a user detects, that an entry is falsy (e.g. "the store does not exist anymore" or "the entry contains false or outdated information"), he should be able to give feedback to the landkreis/stadt responsible who in turn can update the data source with correct information.
  • Add the option to filter by responsible landkreis/stadt on search tab. However, at least for the Bavarian volunteer card, it is quite irrelevant by whom the accepting store is managed, as the card is valid in any other landkreis/stadt.
  • Is there another use case I forgot to mention? Please post any ideas below or update this Issue description.
@michael-markl michael-markl added user story discussion-needed We need to resolve the questions in the issue. labels Jan 25, 2022
@maxammann
Copy link
Member

  • 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).

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.
Maybe it would be good to send changes in batches. So only send this mail once per month with all issues we find.

  • We can add the landkreis/stadt responsible for an accepting store to the details page of the accepting store.

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.

Add the option to filter by responsible landkreis/stadt on search tab.

Good idea for a future Bundesland!

Optionally, we can think about not to apply the sanitization on our end

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)

@maxammann
Copy link
Member

maxammann commented Jan 25, 2022

Should be split into 5 User Stories:

  1. We can add the landkreis/stadt responsible for an accepting store to the details page of the accepting store (easy)
  2. Send suggestions to cities (easy)
  3. Automatically apply suggestions (easy if 4. already done, else hard)
  4. Store user feedback for each Akzeptanzstelle (easy if 3. already done, else hard)
  5. Filter by responsible landkreis/stadt on search tab (easy)

Last but not least: We should not overengineer this :D

@maxammann
Copy link
Member

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.

@maxammann maxammann added prio: high Issue must be solved within the next weeks. and removed low prio labels Feb 15, 2022
@maxammann maxammann added this to the Improve data source milestone Feb 15, 2022
@michael-markl
Copy link
Member Author

I don't think this should be high prio right now. Data quality assurance should be done by regions / freinet / LBE themselves.
Of course it would still be worth looking into. I'd just vote for removing the high-prio tag for now.

@maxammann maxammann added low prio and removed prio: high Issue must be solved within the next weeks. labels Sep 29, 2022
@maxammann maxammann removed this from the Improve data source milestone Nov 21, 2022
@f1sh1918
Copy link
Contributor

f1sh1918 commented Oct 16, 2023

mapping task store to regions is here #538

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion-needed We need to resolve the questions in the issue. user story
Projects
Status: No status
Status: No status
Development

No branches or pull requests

4 participants