Add a "flag bad data" button on various places

mcmanuss8 commented 7 years ago

Idea is you'd see bad data, click a button near it and the info would prepopulate into a popup (but allow it to be editable). The popup would give you some categories to say why it's bad data, and a free text field to give more detail. Click submit would then open a ticket for AC to go work.

arnoldnipper commented 7 years ago

Improving and checking data is part of product com

eloos commented 6 years ago

part of overall data quality. Question is what you would be able to flag and why it should be AC that needs to verify that the data entered by a user is correct or incorrect. What kind of data would this be intended for?

mcmanuss8 commented 6 years ago

Could be anything. Let's consider https://www.peeringdb.com/ix/1 Let's say support@equinix.com is no longer the right email address, and I've tried to get them to fix it...but they don't. There would be a button somewhere on the page that would say "Report bad data". After clicking that I would be able to click a checkbox on any of the fields (including multiple) on the page. After clicking on all the fields that were questionable (the two email address fields in this example), I would then have a free form text which I would fill in to describe why I feel the data is bad.

The generated ticket would include the fields selected, their values (at the time the report was made - in case they get changed later!), and the free text description from the user.

The benefit here is to make it a little easier on the reporter to make the ticket, and make it a little easier to submit data cleanup requests.

arnoldnipper commented 6 years ago

Currently teh paradigm is that only data "owners" are able to modify any data. On the other hand only reporting that the data is bad doesn't really help. What could be done is to flag that data. I.e. if this data set gets reported repeatedly as bad data it would be flagged

mcmanuss8 commented 4 years ago

So what happens now if someone reports bad data (via a support task, email, tweet, whatever), @arnoldnipper? Does AC have a process to follow and such?

For this feature, it would make it a bit simpler for people to report bad data, which is valuable IMO. Downside to doing this could be that you'd get slammed with requests you can't deal with or don't want to deal with. Upside to doing this we could log who else has reported data problems on what objects and de-dupe tickets and/or let people know it's already been reported.

@peeringdb/pc - thoughts?

arnoldnipper commented 4 years ago

So what happens now if someone reports bad data (via a support task, email, tweet, whatever), @arnoldnipper? Does AC have a process to follow and such?

AC looks into the data and follows much like when adding a facility/ix. We try to verify the data. And if we can we will make the change. If not we are asking for more information.

as44980 commented 4 years ago

Currently teh paradigm is that only data "owners" are able to modify any data. On the other hand only reporting that the data is bad doesn't really help. What could be done is to flag that data. I.e. if this data set gets reported repeatedly as bad data it would be flagged

hmm, perhaps in the first N instances the report could go to the account admin(s) for the record in question... and from the N+1 th report this could be flagged to AC to follow up, perhaps using means other than email?

mcmanuss8 commented 3 years ago

@peeringdb/pc consensus on this please? Is it worthwhile to add a button to flag bad data or no?

arnoldnipper commented 3 years ago

I'm reluctant to add this button as it does not tell us what is bad/wrong. Users instead should report any bad data directly to @peeringdb/ac

alexfguimaraes commented 3 years ago

I agree!

With the flag, we can enforce(ask to) user to correct all information pending.

Att Alexandre

On 9 Sep 2020, at 12:35, Arnold Nipper notifications@github.com wrote:

I'm reluctant to add this button as it does not tell us what is bad/wrong. Users instead should report any bad data directly to @peeringdb/ac

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Yo-Robinson commented 3 years ago

+1

On Wed, Sep 9, 2020 at 6:10 PM alexfguimaraes notifications@github.com wrote:

I agree!

With the flag, we can enforce(ask to) user to correct all information pending.

Att Alexandre

On 9 Sep 2020, at 12:35, Arnold Nipper notifications@github.com wrote:

I'm reluctant to add this button as it does not tell us what is bad/wrong. Users instead should report any bad data directly to @peeringdb/ac

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/170#issuecomment-689664288, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOZM2AI4LZMTPNLSUXVBT7DSE6SI7ANCNFSM4DN2B3JQ .

-- Yours Sincerely, Yolandi Robinson

Email: yolandi@peeringdb.com Skype: yolandi.robinson97

DarwinCosta commented 3 years ago

+1.

On 3 Oct 2020, at 10:06, Yolandi Robinson notifications@github.com wrote:

+1

On Wed, Sep 9, 2020 at 6:10 PM alexfguimaraes notifications@github.com wrote:

I agree!

With the flag, we can enforce(ask to) user to correct all information pending.

Att Alexandre

On 9 Sep 2020, at 12:35, Arnold Nipper notifications@github.com wrote:

I'm reluctant to add this button as it does not tell us what is bad/wrong. Users instead should report any bad data directly to @peeringdb/ac

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/170#issuecomment-689664288, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOZM2AI4LZMTPNLSUXVBT7DSE6SI7ANCNFSM4DN2B3JQ .

-- Yours Sincerely, Yolandi Robinson

Email: yolandi@peeringdb.com Skype: yolandi.robinson97 — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

arnoldnipper commented 3 years ago

+1

egfrank commented 3 years ago

Hi moving this to 3a because I have some questions:

1) To clarify, this should affect all objects? 2) How is the "flag bad data" button submission being communicated to the admins?

arnoldnipper commented 3 years ago

@egfrank, happy to answer your question

yes, please for all objects
My understanding is that a text box pops up where the user is able to describe the issue and possible fixes. The content is then taken to open a ticket at DeskPRO. Hence this feature is only available to authenticated users.

@mcmanuss8, do you agree?

mcmanuss8 commented 3 years ago

I agree with that, @arnoldnipper, except I'm not 100% sold on the authenticated user bit.

If the user doesn't have a peeringdb account, they can still manually flag bad data by emailing support, right? Wouldn't we want even unregistered users to submit requests via this mechanism?

Maybe if the user is not logged in, we captcha them to prevent spam coming in via the form?

arnoldnipper commented 3 years ago

It was not because of spamming but to be able to generate a DeskPRO ticket w/o having to ask for an email address. If we want unregistered and unauthenticated users to be able to use this feature that's fine for me.

mcmanuss8 commented 3 years ago

I'm pro-unregistered and pro-unauthenticated users, but I am not going to be dealing with the tickets. :) I defer to your preference here as you will feel the pain, if any

arnoldnipper commented 3 years ago

I do not expect tons of emails to @peeringdb/ac. My preference would be to start with registered and authenticated users, but leave it to the developers. They may decide what it is easier to implement. Does that make sense?

mcmanuss8 commented 3 years ago

I do not expect tons of emails to @peeringdb/ac. My preference would be to start with registered and authenticated users, but leave it to the developers. They may decide what it is easier to implement. Does that make sense?

Works for me, Arnold!

arnoldnipper commented 3 years ago

@egfrank, do you need more input?

egfrank commented 3 years ago

@arnoldnipper thanks for the comment.

One additional point of clarification, where should we put these buttons? For example, looking at the ix view, should there be separate "Flag Bad Data" buttons in the various sections such as "LAN", "Contact Info" etc. Or maybe even individual buttons per ixfac row, netixlan row?

Or is a single "Flag Bad Data" button per major view is enough an all the child objects can be handled in the context of that parent object? So a button at top / bottom of /net /ix /fac and /org views.

arnoldnipper commented 3 years ago

Good question, @egfrank ... on one hand side you want to have the information as close to the bad data as possible. On the other hand, you can't overload the GUI with "Flag Bad Data" buttons.

What about starting with a single "Flag Bad Data" button per major view. And if we find out that this needs refinement we will address this issue again.

alexfguimaraes commented 3 years ago

Just a question, is that possible that the "Flag Bad Data" button, when clicked, it show in a separated tab all "Flag Bad Data"? In this case, one button only will be enough.

arnoldnipper commented 3 years ago

Just a question, is that possible that the "Flag Bad Data" button, when clicked, it show in a separated tab all "Flag Bad Data"? In this case, one button only will be enough.

@alexfguimaraes, where do you want to have that tab?

alexfguimaraes commented 3 years ago

Not a tab inside the portal. When users click the button, it's span a new browser window tab.

It keep the portal clean, and with the new window tab, the user can compare the appointments.

arnoldnipper commented 3 years ago

Not a tab inside the portal. When users click the button, it's span a new browser window tab.

It keep the portal clean, and with the new window tab, the user can compare the appointments.

@egfrank, could you please respond.

leovegoda commented 2 years ago

We discussed a proposed implementation for this issue last week. I have updated it below. @peeringdb/pc please take a look and either +1 it or identify the specific improvements needed before we can implement this feature:

Create one button on each “object” page enabling users to report data errors.
When users click the button they are asked to select each key with an error.
We should present users with one free text box to explain why the data is erroneous. Give it a maximum size of at least 500 characters.
Users should be able to attach a screenshot but no other attachments.
We should show the selected keys and supporting text to the user in a dialogue box and ask them to confirm or cancel. If they choose to cancel the dialogue closes without any action being taken. If they choose to confirm the report we create a Deskpro ticket.

arnoldnipper commented 2 years ago

We should show the selected keys and supporting text to the user in a dialogue box and ask them to confirm or cancel. If they choose to cancel the dialogue closes without any action being taken. If they choose to confirm the report we create a Deskpro ticket.

We should show the selected keys and supporting text to the user in a dialogue box and ask them to confirm or cancel. If they choose to cancel the dialogue closes without any action being taken. If they choose to confirm the report we create a Deskpro ticket. This ticket is sent to the sender and the admins of the object, only.

leovegoda commented 2 years ago

We should show the selected keys and supporting text to the user in a dialogue box and ask them to confirm or cancel. If they choose to cancel the dialogue closes without any action being taken. If they choose to confirm the report we create a Deskpro ticket.

We should show the selected keys and supporting text to the user in a dialogue box and ask them to confirm or cancel. If they choose to cancel the dialogue closes without any action being taken. If they choose to confirm the report we create a Deskpro ticket. This ticket is sent to the sender and the admins of the object, only.

Doing this seems fine to me as long as we inform the person clicking the button who will get the message when they confirm.

martinhannigan commented 2 years ago

-1

I thought about this quite a bit. We do want accuracy. However, we also want efficiency. Owners should be asked to opt-in or be allowed to opt-out. Otherwise, the mail is likely to fall into random email buckets and be equivalent to spam due to the opt-in nature. This approach seems to be lower on the priority list than higher IMHO.

You can lead a fish to water, but you can't make them drink.

On Thu, Mar 10, 2022 at 10:28 AM Leo Vegoda @.***> wrote:

We should show the selected keys and supporting text to the user in a dialogue box and ask them to confirm or cancel. If they choose to cancel the dialogue closes without any action being taken. If they choose to confirm the report we create a Deskpro ticket.

We should show the selected keys and supporting text to the user in a dialogue box and ask them to confirm or cancel. If they choose to cancel the dialogue closes without any action being taken. If they choose to confirm the report we create a Deskpro ticket. This ticket is sent to the sender and the admins of the object, only.

Doing this seems fine to me as long as we inform the person clicking the button who will get the message when they confirm.

— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/170#issuecomment-1064184769, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQWCT5DESVG23XL7IBDU7IILRANCNFSM4DN2B3JQ . You are receiving this because you are on a team that was mentioned.Message ID: @.***>

arnoldnipper commented 2 years ago

You can lead a fish to water, but you can't make them drink.

Wasn't that a horse?

martinhannigan commented 2 years ago

It was but the analogy is better suited for this topic as is.

On Fri, Mar 18, 2022 at 8:39 AM Arnold Nipper @.***> wrote:

You can lead a fish to water, but you can't make them drink.

Wasn't that a horse?

— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/170#issuecomment-1072372411, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQQGKHDJSHHJLZCON5TVAR2QHANCNFSM4DN2B3JQ . You are receiving this because you are on a team that was mentioned.Message ID: @.***>

mcmanuss8 commented 1 year ago

Per discussion today the main concern is the level of effort. Let's make this a really simple/low effort approach:

Add a button on each object (org, net, ix, fac, carrier) near the top (next to sponsorship tag?).
Clicking the button either pops up a mailto: link to support@ with the below body (or a modal if it's a small lift to do that instead):

I am seeing bad data with $object_type at $url. 
 The field(s) in question are:
     {please fill in}

 I think this is bad data because:
    {please fill in reason you're flagging this as bad data}

 The correct data is probably:
    {please fill this in if you feel strongly you know what the correct data should be}

I'm neutral on whether a user needs to be logged in to click said link/have it displayed. A benefit to mailto: is we'd automatically get a user's contact info if they aren't logged in/forgot to login.

@peeringdb/pc please vote

Future work here that we will consider out of scope until we see the feature being used significantly:

Contacting the record's owner and escalating to AC only if they are unresponsive
Fancier selection of which fields are flagged
Showing other users that some data was flagged on this but not yet resolved
Translating to other languages (a pro for the modal approach)

martinhannigan commented 1 year ago

+1

On Thu, Jan 5, 2023 at 12:29 mcmanuss8 @.***> wrote:

Per discussion today the main concern is the level of effort. Let's make this a really simple/low effort approach:

-

Add a button on each object (org, net, ix, fac, carrier) near the top (next to sponsorship tag?).

Clicking the button either pops up a mailto: link to support@ with the below body (or a modal if it's a small lift to do that instead):

"I am seeing bad data with $object_type at $url. The field(s) in question are:

I think this is bad data because: <please fill in reason you're flagging this as bad data> The correct data is probably:

"

I'm neutral on whether a user needs to be logged in to click said link/have it displayed. A benefit to mailto: is we'd automatically get a user's contact info if they aren't logged in/forgot to login.

Future work here that we will consider out of scope until we see the feature being used significantly:

Contacting the record's owner and escalating to AC only if they are unresponsive

Fancier selection of which fields are flagged

Showing other users that some data was flagged on this but not yet resolved

Translating to other languages (a pro for the modal approach)

— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/170#issuecomment-1372518484, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQREARQPN4IH5QBXOUDWQ4AJBANCNFSM4DN2B3JQ . You are receiving this because you are on a team that was mentioned.Message ID: @.***>

grizz commented 1 year ago

+1

zetserverscom commented 2 months ago

+1

peeringdb / peeringdb

Add a "flag bad data" button on various places #170

Add a button on each object (org, net, ix, fac, carrier) near the top (next to sponsorship tag?).

"