Adjust matching estimates to better represent Cluster Match (COCM) algorithm

[koday1]

We have recently implemented Cluster Matching (COCM) - https://forum.giveth.io/t/cluster-match-qf-announcement/1419

As a result, the current matching estimates during a QF round are now very inaccurate. We need to implement a fix to account for the new matching algorithm.

I think the best way to do this is by showing the matching estimate as a range (i.e. $25-$150) and then adding a note in the UI that the more projects a user donates to in the QF round, the more likely they are to get a higher match.

@CarlosQ96 I have assigned this to myself for now so I can create a plan for implementing this. Afterward, I will assign the issue to you and add the steps + documentation here. My goal is to have this finished and tested before the GIV-Earth round starts on June 25.

This is a new version/related to https://github.com/Giveth/giveth-dapps-v2/issues/2944

cc @laurenluz

[koday1]

@Meriem-BM Are you able to take this issue?

I talked with Carlos and we think the simplest way to adjust matching right now is to display a range in the UI without changing anything in the backend.

This range will be 30% - 100% of the calculated QF match.

For example, if the calculated estimated match for a user donating is $100, we would change that to display "$30 - $100" estimated match.

If you could make this adjustment in the UI with a note that says, "Donate to more projects to receive higher matching!" that would be awesome.

Let me know if that makes sense or if you have any questions. Thanks!

[laurenluz]

@koday1 try to be more clear with the requirements. if you want a note in the UI... you should say where. if it is new, you can ask Mo or a designer to mock it up... if you want to replace existing copy, take a screenshot and highlight it so the dev knows where to make the change.

If you want to change the estimated match you should outline which places it should be changed. is it everywhere it appears? or only in some places? for example. I think it adds extra confusion to add a "range" to esimated matching on the donate page.

I see Meriem has already done some work on this and it's in UAT/QA, but imo the set up of the issue is too vague for things to follow advice process & testing.

[koday1]

@laurenluz Thank you - those are great points and I agree that the info shared on this issue is too vague overall but in this case the details you mentioned were worked through in DMs with Carlos and Meriem.

I should have posted an update here but got carried away working through the UI changes and everything in DMs. Meriem came back to me a few times with examples and I advised her on where the updates would be shown along with the donor message. I'm happy with the result thus far but I can add another comment with more details if you think that's a good idea for advice/testing

[laurenluz]

yes the breakdown should be done added to the issue so that they can be reference and used for testing. DMs are good for hashing through something, but you need a central source of truth and it's better if it's not hidden in DMs.

[koday1]

Update on the matching estimate work done via this issue:

@Meriem-BM and I worked through adjusting the UI everywhere matching is shown to display a range from 30% of calculated QF match to 100% of calculated QF match. If the estimated match is calculated to be $0, it will stay at $0 instead of showing a range. A huge kudos to Meriem for getting this done quickly!

Here are the details of all the changes:

/QF homepage:

• The matching estimate for each project shown on the /QF page is now a range

Project page:

• The matching estimate for the project is now a range (and should be the same range as seen on the homepage)
• The matching estimate table for contributions of $1, $10, and $100 are now all shown as a range

Donation checkout:

• The matching estimate is shown as a range when the user enters a donation amount
• The message under the donor matching estimate had the sentence "Donate to more projects to receive higher matching!" added to it
• The project estimated matching on the right side of the page is now a range

cc @laurenluz

[laurenluz]

@Meriem-BM when the matching is less than $1, we should just show "<$1" (not a range) in every place.

[Meriem-BM]

@Meriem-BM when the matching is less than $1, we should just show "<$1" (not a range) in every place.

Yes, I actually handled that case, but what you see there <1$ - 1$ is when the 30% of estimated matching is less than 1$, and estimated matching is 1$, should I show <= 1$ ?

[Meriem-BM]

@laurenluz we have to options either we put accurate range for this case (Float numbers)

or we put < $2

WDYT?

[Meriem-BM]

For this case where you see range between $1 and less than $1 is where the estimated matching is < $2 Ex: $1.45

[maryjaf]

• The matching estimate is shown as a range when the user enters a donation amount

• [ ] when the donation amount is low, In donation page the below pic is shown, is this expected result ?

[Meriem-BM]

• The matching estimate is shown as a range when the user enters a donation amount

• [ ] when the donation amount is low, In donation page the below pic is shown, is this expected result ?

https://github.com/Giveth/giveth-dapps-v2/issues/3829#issuecomment-2188559875

[laurenluz]

This issue was merged to prod?? please revert back ASAP

[laurenluz]

When the matching pool is not in $, the range looks really weird on the project card, and needs to be reformatted. If we end up going back to this range method, we will need to work on the design before re-implementing.

But I think we should work with @mosaeedi and get some feedback from folks in the QF team before moving forward with this change. Imo the range doesn't actually better represent COCM if it's just a 30-100%... why make things more complicated for the user by showing them an range approximation of an approximation? this doesn't actually encourage them to really donate to a more diverse set of projects, and I think just makes things more clunky and harder to understand.

[CarlosQ96]

whats the status on this issue @Meriem-BM ?

[Meriem-BM]

whats the status on this issue @Meriem-BM ?

It was reverted, @laurenluz, are we planning something for this issue?

[koday1]

@Meriem-BM @CarlosQ96 This is still on hold for now. I included it in the "Sustain" scope for the QF working group, but we will not be able to implement this before the GIV-ARB round that starts on July 30.

We need to scope out a better solution than my proposed "range" method, so I will close this issue and we will start fresh when we begin working on updating our matching calculations in the future.

cc @laurenluz