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

email rollup for standard transactions on gitcoin grants #8917

Closed
5 tasks done
frankchen07 opened this issue May 19, 2021 · 9 comments · Fixed by #9064
Closed
5 tasks done

email rollup for standard transactions on gitcoin grants #8917

frankchen07 opened this issue May 19, 2021 · 9 comments · Fixed by #9064
Assignees

Comments

@frankchen07
Copy link
Contributor

frankchen07 commented May 19, 2021

Circumstance

Using bulk checkout allows for an email rollup, we should do the same for standard checkout so folks who donate to more than 40+ grants don't get bombarded with hundreds of grant emails.

Description

  • implement email rollup according to cart size
  • how do we rollup for standard checkout (where I believe the problem exists)

for grant owners:

  • have an email sent out every cron job interval
  • on the email itself, there will be no actual contributor or individual contribution details, instead, we will add aggregate metrics and link them to their grant activity feed
  • "in the last 6 hours your grant has earned approximately $$$ from XXX users, please click here to see more"
@thelostone-mc
Copy link
Member

I'm not clear on the flow here. Checkout can be done it 2 ways

  • Zksync Bulk checkout
  • Standard Bulk checkout

And AFAIK -> we do email rollup for both. Could you clarify more on this ?

@frankchen07
Copy link
Contributor Author

to confirm, for both versions of checkout, we do bulk emails for both? (sent to a contributor)?

how about for grant owners?

@thelostone-mc
Copy link
Member

for contributor -> that was solved here: #8258
for grant owners -> this wouldn't apply cause we won't be able to group them cause the trigger point is from the contributor

@frankchen07
Copy link
Contributor Author

for grant owners -> this wouldn't apply cause we won't be able to group them cause the trigger point is from the contributor

so are you saying the grant owner does or doesn't receive emails based on someone contributing to their grant?

@thelostone-mc
Copy link
Member

the grant owner does receive emails based on someone contributing to their grant!

@frankchen07
Copy link
Contributor Author

gotcha, and are those also rolled up?

I believe this we still have to discuss, right? I recall Graham saying they are not and there's an exception to why that is the case.

@thelostone-mc
Copy link
Member

might be worth hoppin on a call and discussing this !
Rollups don't happen on funder cause they get contributions from people randomly at a different point in time.
The solution which is being proposed by @gdixon is not sending out emails asap when a funder gets a contributions and group them up and send them once a day / every 6 hours (whatever we deem fit)

I don't think this is super needed right now but if we want to pull this off.
A couple of things which might need to be discussed :

  • this might need a email redesign (not sure cause you're giving a summary report) as opposed to instant updates
  • we have sign off from team cause this means you WILL NOT get an email immediately when you receive a contribution
  • engineering-related : finally see if it can be done without adding a new column to contribution / subscription table. maybe each time the command is run
  • finally what do we do about contributions that are in pending / failed when this rollup email thing is sent out

@willsputra
Copy link
Contributor

maybe something like this? @frankchen07 @thelostone-mc
grants_grant-owner

@willsputra
Copy link
Contributor

@frankchen07 cc @PixelantDesign updated based on feedback + responsive view
Slice 1(1)

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

Successfully merging a pull request may close this issue.

4 participants