Re: [Snowdrift-dev] Brainstorm for implementing multiple projects

[Aaron Wolf]

On 11/15/2017 05:24 AM, Jason Harrer wrote:
> After thinking about it for awhile, I'd like to propose an alternate
> recommendation for the crowdmatch step under budget calculations.  I
> will start off saying that your approach will be far simpler to
> implement and less resource-intensive than mine, however I'm still
> proposing my recommendation based on prior conversations that were made
> pertaining to letting the patron decide what projects are their
> priorities (note: I'm not suggesting that we set that up now, rather I
> believe my recommendation would better accommodate that functionality
> should you decide to implement the patron prioritization /later,/ so it
> may be beneficial to look at and possibly set up the alternate approach
> now to prepare for future changes).
> 
> The idea is to set up one or two temporary "tables" (not sure if it
> would be preferred to do this via postgresql or simply have two mapped
> lists via Haskell, so I will use the term "tables" to represent whatever
> this agreed-upon structure ultimately is).
> 
> The first "table" would hold the calculated pledged dollar amounts per
> project (at this point, the calculation assumes no one has exceeded
> their limit).
> 
> Then, the automation will review each patron to determine if any exceed
> their limit.  If so, the system needs to drop a/multiple pledge[s] to
> get the user under their limit.  I recommend the logic to drop the
> multiple pledges be a separate function that is called from the primary
> logic (thus allowing you in the future, should you decide to go down
> that path, to easily switch out the logic from a LIFO/FIFO function to a
> patron prioritization function or any other type of function that you
> think of later) and adjust the temporary "table" pledged dollar amounts
> accordingly.
> 
> Optionally, as an addition to the last paragraph, the logic could store
> the dropped pledges in a second temporary "table".  The idea behind the
> second "table" is this:  Once all of the adjustments to the project
> calculated pledged amounts are made across all the patrons, this may
> reduce down the pledged amounts of enough projects that a patron pledged
> to that we might actually be able to add some pledges back in, should we
> want to go down that road.  The con is obviously complexity:  This would
> mean a second pass to review the dropped pledges and determining if
> adding a pledge back in would impact other patrons, so there'd be a LOT
> of additional calculation needed to ensure that adding back pledges
> doesn't cause other issues.  The pro, though, is that we could be
> getting additional funds to the projects.
> 
> Obviously, the call is yours, but I wanted to put the idea out there for
> you to ponder upon.
> 
> - Jason (JazzyEagle)
> 

Two general points to clarify re: Jason's thoughts:

1. Pledges to one project should only ever make that *same* project lose
pledges due to budget issues. We avoid a wide range of complexities if
we never let projects interact where pledge to one directly drops
pledges to another.

2. The buffer requirement for new pledges removes a wide range of
expensive calculations and volatility. A patron who hit their limit will
need to drop enough to have a good buffer left in their budget or
increase their budget substantially before they can add *any* pledge
back. So, we can avoid all scenarios where someone is almost at their
budget and then comes back active but is again immediately approaching
their budget. Every time a budget is hit, reinstatement will require a
buffer so we don't get pulsing adds and drops of pledges.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Brainstorm for implementing multiple projects

[Aaron Wolf]

On 11/07/2017 04:34 AM, Bryan Richter wrote:
> Hi all,
> 
> Here are some initial ideas for implementing multiple projects in the
> crowdmatch library. (This is not about the website.) Please take some
> time to read this and provide any feedback or fresh ideas, since I
> dreamed this up on my own, and I could use some second opinions.
> 
> Thanks!
> 
> ---
> 
> 
> Having multiple projects means it becomes more complicated to see if
> someone has gone over their budget. We'll need to account for that.
> 

We discussed this a while back. I'm going to summarize again here some
basic (maybe obvious) factors.

We only need to check for budget-limits at the time of new pledges, and
any budget limits hit will only affect the patrons of the project that
received the new pledge.

While this may eventually be computationally intense, it won't be too
extreme early on. The process as I'd expect would be to check the budget
status of all the existing patrons to one project when that project
receives a new pledge. It could be done in some sensible order such as
oldest patron first. As soon as a single patron is determined to go over
their budget, their pledge is deactivated and no further budget checking
is needed. If the checking gets through all the patrons without issue,
then nobody is over budget.

> Crowdmatching and payment processing both become more complicated,
> too. Besides checking budget limits (which will have a life of their
> own for the sake of early warnings), crowdmatching will have to group
> by project when calculating crowd size.
> 
> The existence of a pledge will need to change from being a Maybe field
> in the User row to being a Maybe field in the Pledge list. It stays
> a Maybe so that one table handles the whole relationship: pledge
> status and pending donation.
> 
> Here's the plan for handling spending limits: Don't charge more
> than the limit, and don't allow a crowdmatch that is greater than
> the limit. Note what's left out: we do not consider the pending
> balance (if any) when doing a crowdmatch, but only the spending limit
> itself. In the possible case that a crowdmatch of, say, $3 causes a
> user's balance to be $11, they can pay $10 this month, and $4 next,
> and that's fine.
> 
> We need is to extend the calculations to be per-project, hitting the
> pledge table instead of the user table.
> 
> -  Tasks for enabling multiple projects
> -  Dev tasks
> -  Modify tests to assume multiple projects
> -  Create new Project table (id, handle, donations_received)
> -  Create new Pledge table,   user <*--*> project
> -  Deprecate pledge_since

Why deprecate pledge_since? Certainly we don't want to lose the
information about how long someone has been a patron. Also, my idea (not
sure it's strictly the best though) to check in order from oldest to
newest pledge would seem to use some information like this.

> -  Implement budget limit calculations (below)
> -  Deploy tasks
> -  Migrate pledges and pending donations
> -   insert into pledge (project, user, since, pending_donation)
> select 1, u.id, u.pledge_since
> from user u
> -  Budget calculations
> -  During crowdmatch
> -  Drop pledge LIFO, recalculate, and repeat until nobody exceeds 
> their limit
> -  Continue with crowdmatch
> -  When patron views a page
> -  Change nothing, just show warnings
> -  During payment processing
> -  Only charge up to the limit, leaving any extra in the patron's 
> account.
> 

Are you suggesting that staying pledged but over-budget between
crowdmatches will happen? That trade-off may be necessary, but we should
clarify.

From the front-end perspective, the assumption is that a patron is
notified of hitting their budget *before* the crowdmatch happens so that
they can choose to adjust their budget or their set of pledges prior to
the crowdmatch (unless the budget was hit with too little time before
the crowdmatch).

Overall, this does bring up a ton of questions. There needs to be some
understanding between front-end design and dev here. Front-end has to
work with that is practical for dev, of course.

### concerns

If multiple patrons hit their budgets at the same time (say they pledge
to the same set of projects), who gets dropped first?

If a patron with a dropped pledge decides to drop a different pledge in
order to reinstate the dropped one, I guess any patrons who also support
the same two projects would be budget-wise unaffected since they would
just reduce their level for one and increase for the other. I guess it
would be unlikely for their to be multiple patrons all close to their
budgets at the same time if the set of projects they support are really
different sets, right?

BUFFER: to keep things from being too volatile, we've had this concept
for a long time that there should be some buffer remaining in a patron's
budget in order to add a new 

Re: [Snowdrift-dev] Go to Definition?

[Aaron Wolf]

In general, please anyone on this thread:

If you clarify suggestions that can be good for new contributors with
little or no qualifications, submit merge-request changes to the
TEXTEDITORS.md document.

While we can't take on every issue in the Haskell ecosystem, we
certainly have an interest in lowering the barriers to productive
contributions from volunteers.

Thanks!



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Go to Definition?

[Samuel Tay]

>
>
> haskdogs sounds like it's solving a similar problem to codex. Any
> insight to their relative strengths and weaknesses?
>
>
Oh wow. I was not aware of codex, so I can't compare them, but I'll
definitely be trying that out. At first glance, I think haskdogs is stack
specific and codex is not, so that's a point for codex. Thanks for
mentioning!
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Go to Definition?

[Bryan Richter]

On 11/14/2017 11:04 AM, Samuel Tay wrote:
> Hasktags generates pretty much all the tags you want relevant to
> your project. If you have git submodules, forks of other projects
> locally, etc. then you can pass these directly via the CLI, e.g.
>
> hasktags -b "src deps/package1 deps/package2 /some/other/location"
>
> Another cool tool built off hasktags is haskdogs, which recursively
> generates tags. Might only be for stack projects, and also might
> only be viable for smaller projects, but I use it locally and it's
> awesome! You'll get jump-to for all of base as well (you get sent to
> some file in your .stack-work directory).
>
> https://hackage.haskell.org/package/hasktags
> https://hackage.haskell.org/package/haskdogs

Thanks, I'm gonna try this out!

haskdogs sounds like it's solving a similar problem to codex. Any
insight to their relative strengths and weaknesses?



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Go to Definition?

[Bryan Richter]

On 11/14/2017 12:02 PM, David Thomas wrote:
> While the general case for TH is intractable, it would probably be
> pretty simple to write a script that can generate tags locations for
> identifiers generated by specific, known cases - particularly
> Persistent.
>
> At work I took a bit of a different approach, and wrote a generator
> that looks at the TH output and writes out code to different modules
> for each model.  This lets the tooling just work.  Probably
> overkill in the context of Snowdrift, though...

Sounds like something Haskell needs in general! I agree that the case
of persistent and routes is much simpler, though.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Brainstorm for implementing multiple projects

[Jason Harrer]

After thinking about it for awhile, I'd like to propose an alternate
recommendation for the crowdmatch step under budget calculations.  I will
start off saying that your approach will be far simpler to implement and
less resource-intensive than mine, however I'm still proposing my
recommendation based on prior conversations that were made pertaining to
letting the patron decide what projects are their priorities (note: I'm not
suggesting that we set that up now, rather I believe my recommendation
would better accommodate that functionality should you decide to implement
the patron prioritization *later,* so it may be beneficial to look at and
possibly set up the alternate approach now to prepare for future changes).

The idea is to set up one or two temporary "tables" (not sure if it would
be preferred to do this via postgresql or simply have two mapped lists via
Haskell, so I will use the term "tables" to represent whatever this
agreed-upon structure ultimately is).

The first "table" would hold the calculated pledged dollar amounts per
project (at this point, the calculation assumes no one has exceeded their
limit).

Then, the automation will review each patron to determine if any exceed
their limit.  If so, the system needs to drop a/multiple pledge[s] to get
the user under their limit.  I recommend the logic to drop the multiple
pledges be a separate function that is called from the primary logic (thus
allowing you in the future, should you decide to go down that path, to
easily switch out the logic from a LIFO/FIFO function to a patron
prioritization function or any other type of function that you think of
later) and adjust the temporary "table" pledged dollar amounts accordingly.

Optionally, as an addition to the last paragraph, the logic could store the
dropped pledges in a second temporary "table".  The idea behind the second
"table" is this:  Once all of the adjustments to the project calculated
pledged amounts are made across all the patrons, this may reduce down the
pledged amounts of enough projects that a patron pledged to that we might
actually be able to add some pledges back in, should we want to go down
that road.  The con is obviously complexity:  This would mean a second pass
to review the dropped pledges and determining if adding a pledge back in
would impact other patrons, so there'd be a LOT of additional calculation
needed to ensure that adding back pledges doesn't cause other issues.  The
pro, though, is that we could be getting additional funds to the projects.

Obviously, the call is yours, but I wanted to put the idea out there for
you to ponder upon.

- Jason (JazzyEagle)


On Tue, Nov 7, 2017 at 6:34 AM, Bryan Richter  wrote:

> Hi all,
>
> Here are some initial ideas for implementing multiple projects in the
> crowdmatch library. (This is not about the website.) Please take some
> time to read this and provide any feedback or fresh ideas, since I
> dreamed this up on my own, and I could use some second opinions.
>
> Thanks!
>
> ---
>
>
> Having multiple projects means it becomes more complicated to see if
> someone has gone over their budget. We'll need to account for that.
>
> Crowdmatching and payment processing both become more complicated,
> too. Besides checking budget limits (which will have a life of their
> own for the sake of early warnings), crowdmatching will have to group
> by project when calculating crowd size.
>
> The existence of a pledge will need to change from being a Maybe field
> in the User row to being a Maybe field in the Pledge list. It stays
> a Maybe so that one table handles the whole relationship: pledge
> status and pending donation.
>
> Here's the plan for handling spending limits: Don't charge more
> than the limit, and don't allow a crowdmatch that is greater than
> the limit. Note what's left out: we do not consider the pending
> balance (if any) when doing a crowdmatch, but only the spending limit
> itself. In the possible case that a crowdmatch of, say, $3 causes a
> user's balance to be $11, they can pay $10 this month, and $4 next,
> and that's fine.
>
> We need is to extend the calculations to be per-project, hitting the
> pledge table instead of the user table.
>
> -  Tasks for enabling multiple projects
> -  Dev tasks
> -  Modify tests to assume multiple projects
> -  Create new Project table (id, handle, donations_received)
> -  Create new Pledge table,   user <*--*> project
> -  Deprecate pledge_since
> -  Implement budget limit calculations (below)
> -  Deploy tasks
> -  Migrate pledges and pending donations
> -   insert into pledge (project, user, since, pending_donation)
> select 1, u.id, u.pledge_since
> from user u
> -  Budget calculations
> -  During crowdmatch
> -  Drop pledge LIFO, recalculate, and repeat until nobody exceeds
> their limit
> -  Continue with crowdmatch
> -  When