Discussion about switching back to live algorithm

[taoeffect]

Problem

Copying from the ux/design channel:

@Leihla If I recall correctly, your argument (and maybe @corrideat?) for not going with the “live” algorithm was that if someone joins a day later after a pledger paid, that they would be paid less, and that it was “unfair” because of that. Yet with the distribution date algorithm, that’s basically what happened in our group, except worse - now because someone entered their payment details a day late, they get nothing and have to wait for an entire month. That wouldn’t happen with the other algorithm. How do you defend this? 😛 At least with the other algorithm they at least get paid something in all likelihood, and up to the entire amount that’s expected if they entered their payment details before any other payments were made Also, with the other algorithm people can edit their income details still if they made a mistake. With the distribution-date approach the income details are fixed and cannot be edited for a whole month

Solution

Switching back to the other algorithm is still possible, and should be easier to do than it was to switch to the distribution-date algorithm, because we have the old code still and the way the distribution-date stuff is implemented in a generic kind of way.

I propose that we do it for the above reasons, but if there are objections or reasons you think we shouldn't, please discuss them below.

[taoeffect]

We could also combine some aspects of both of them. Keep the "live/reactive" algorithm, and also keep the 30 day periods of the distribution-date posthumous algorithm.

Edit: keeping the 30 day periods would make it easier to switch between the two algorithms, even make it possible to have it be a setting potentially.

[corrideat]

Originally, I saw only advantages with the posthumous algorithm because it makes the results very predictable and easy to understand. I still like it for this.

However, I came to realise that a live approach might be needed regardless, because people are not necessarily going to honour their pledges (or, conversely, might decide to increase their contribution over their original pledge, although this case is perhaps less severe). The situation I'm concerned about, specifically, is illustrated by this example:

• Alice and Bob both pledge $50
• Carol and Dan both need $25.

With the posthumous algorithm, Alice and Bob would both have to pay $25. Let's say Alice is meant to pay Carol $25 and Bob Dan $25.

However, let's say that for some reason Bob is not able to meet his pledge. If we have only the posthumous approach, this means that Carol receives $25 but Dan receives nothing (note that if Alice is going to honour her pledge in full, there are enough funds to cover Dan).

Of course, the group could come to some out-of-band agreement in this case, such as Alice covering for Bob. However, I think that it could be useful to allow people to re-adjust their pledges as I think situations like these will invariably arise.

On the other hand, I think the live algorithm can behave in ways that can be difficult to understand and that can lead to situations that are unfair or unexpected. Maybe an alternative approach is to combine the two, introducing some way of tracking what was actually fulfilled (say, by someone changing what they're willing to commit), and offering an alternative distribution if there are changes.

[leihla]

Hey!

The problem that we were running into with the live algorithm was the following:

• Alice and Bob both pledge $50
• Carol needs $50 and Dan needs $50

Overall, the group has enough money to cover both needs (100 pledged and 100 needed) With the live algorithm and adjusted for payment methods, the distribution might look like this:

• Alice pays Carol 50 | Bob pays Dan 50.
• On April 24, Alice pays Carol - which means there's now a need of 50 remaining for Dan which should be paid by Bob
• On April 25, Bob changes his pledge and can no longer transfer money.
• This scenario would leave Dan with 0 help and Carol with 50$ which seems unfair as both had the same need

This situation would be helped if there's a specific date in which people know they will have to transfer payments and lock in their pledges and needs. If this posthumous algorithm does not work, I'm not opposed to move to the previous one, but this scenarios will happen frequently as users without a define payment day, will do payments as they will and group members inevitably get supported in unequal ways.

[taoeffect]

Thanks for the perspectives and examples guys.

Regarding this scenario:

Alice pays Carol 50 | Bob pays Dan 50. On April 24, Alice pays Carol - which means there's now a need of 50 remaining for Dan which should be paid by Bob On April 25, Bob changes his pledge and can no longer transfer money. This scenario would leave Dan with 0 help and Carol with 50$ which seems unfair as both had the same need

Tbh I remember a different scenario being discussed, let's go with this though. In this situation, the posthumous algorithm doesn't help much either. GI does not force anyone to do anything. This same scenario can happen with the posthumous algorithm, except that instead of the algorithm knowing that Bob wasn't paying, it would not know, meaning it wouldn't be able to re-allocate any other pledges, and so Dan is really left with 0, whereas in the live algorithm, pledges can be increased, or new members can join, and so Dan has a greater chance of receiving something rather than nothing — in the posthumous algorithm, receiving nothing is guaranteed. Furthermore, Bob is also left frustrated that the software won't allow him to adjust his pledge for this month.

I'm not opposed to move to the previous one, but this scenarios will happen frequently as users without a define payment day, will do payments as they will and group members inevitably get supported in unequal ways.

In the current approach, there also is no payment day, only a day when the distribution is locked in. In both algorithms there is a payment period.

However, implementing the posthumous approach did lead to some improvements that we can carry over to the live algorithm as well. This includes the designs for warnings for people to enter or update their payment details as the next payment period approaches. We'll keep those.

So it sounds like there aren't any strong arguments for staying with the posthumous algorithm, so I'll open an issue and self-assign to switch back to the live algorithm, but will leave this issue open until the switch is done in case there's any interest in going over other scenarios.

[taoeffect]

Woah. I just realized that my implementation of the posthumous algorithm is not entirely posthumous...

So what I wrote above in the quoted Slack message would have been true if it were. However, in my implementation, the entire distribution only actually locks in once someone has completed a payment.

This is good news & bad news:

• Good news: currently, people can adjust their income details after the distribution date, until someone sends a payment. I didn't notice this because the payment minimizer hid the other person from me.
• Bad news: @dotmacro pointed out the following scenario, which affects both the current implementation of posthumous and the live version (but not the correct version of posthumous):
  • She was told to pay Person A. People adjusted their income details. Had she gone and paid this person without noticing the new distribution, she wouldn't be able to report it in the UI, because the distribution had changed and now she was being told to pay Person B. This is an issue that appears only with the Manual Payment mode and anything other than the correct implementation of posthumous.

There were minor technical reasons I implemented it this way, but tbh they aren't very valid. The correct implementation should have been done.

So, this is a real tradeoff we need to consider, as with manual payment it will definitely be confusing if the algorithm switches who you're being asked to pay while you're in the middle of paying someone. It will only be a real issue while we are using manual payments with either this version of posthumous or the live algorithm.

Implementing the correct posthumous can be done as well, but then we have the above fairness related issues.

The ideal seems to be the live version with lightning payments implemented.