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

Follow up mail to the correction submitter #317

Open
drdhaval2785 opened this issue Oct 30, 2016 · 8 comments
Open

Follow up mail to the correction submitter #317

drdhaval2785 opened this issue Oct 30, 2016 · 8 comments
Assignees

Comments

@drdhaval2785
Copy link
Contributor

@funderburkjim
I am not sure whether this is actually implemented or not.
This suggestion is triggered by the observation here

Case 23548: 10/12/2016 dict=AP90, L=31590, hw=hradrogaḥ, user=anoojmuljee
old = current word hradrogaḥ is wrong and it rather starts with hṛd, not hrad
new = hradrogaḥ ought be corrected to hṛdrogaḥ
status =  No change needed. 10/16/2016

We have declined to correct the correction submitted by a user.

We should send a mail to the user with details like

Your XYZ correction is installed on DDMMYYYY

or

Your XYZ correction does not need correction because of this reason : ABC

This way the user will have a follow up message from our side.
This may increase user engagement with our cause.

@gasyoun
Copy link
Member

gasyoun commented Oct 30, 2016

This may increase user engagement with our cause.

Fully agree, makes sense. Can you write one, Dhaval?

@funderburkjim
Copy link
Contributor

When a correction form user leaves an email address, I sometimes respond.
The informal rules of when a response is sent or not sent:

  • If the correction is NOT made, I'll usually give an explanation of the reasoning in an email
  • If this is the first time a user submitted a correction, I'll usually send a 'Thank you' email
  • If the user is a frequent submitter, and I have previously sent an email, I'll usually not send one for
    a run of the mill correction.
  • If I think the correction is especially interesting for some reason, I'll usually mention that in an email

In actual practice, I will send an email response in a very small portion of the correction form cases.
This is due to:

  • no email provided. For instance, some user has submitted many corrections to GRA, but he/she
    leaves no contact info.
  • Repeat customers. Most of the corrections are by 'repeat customers', those who have submitted
    numerous corrections over the years, and whom I have sent Email 'Thank you' notes .

@drdhaval2785
Copy link
Contributor Author

drdhaval2785 commented Oct 31, 2016 via email

@drdhaval2785
Copy link
Contributor Author

drdhaval2785 commented Oct 31, 2016

Dear USER,

We regret to inform you that your correction submission with the following
detail could not be accepted because of the following reasons

CORRECTION DETAILS

REASON : XYZ

Please feel free to draw our attention if we have missed to understand what
you wanted to convey.
We look forward to more corrections from your side.

From,
Jim Funderburk
webmaster Colone Sanskrit Dictionaries

@gasyoun
Copy link
Member

gasyoun commented Oct 31, 2016

Dhaval, you think it could improve activity? Indeed some feedback might make one feel happy. But I would use email templates (as Dhaval proposes) and use our Google Docs tables + Google Docs emailer script that would be easier (at least for me), so it would not distract me.

@funderburkjim
Copy link
Contributor

@drdhaval2785 Your two form-letter templates are indeed similar to the response I provide, when I do
so on an irregular basis as I described above.

Are you suggesting that a response be generated for ALL user corrections?

@gasyoun
Copy link
Member

gasyoun commented Oct 31, 2016

Are you suggesting that a response be generated for ALL user corrections?

I guess he wants so.

@drdhaval2785
Copy link
Contributor Author

drdhaval2785 commented Oct 31, 2016 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants