Allow team takes to be specified in shares not just $.

[pjz]

Currently takes can only be specified in $. Allow them to be specified as percentages [see below] in shares of income. The dollar amount should also be shown nearby for easy of use.

[chadwhitacre]

IRC

[pjc]

I can see percentages work when the project is small and everybody is underpaid anyway.

When the project becomes better funded and people take full time salaries anyway, dollar amounts will work better because unlike percentages it leaves the new dollars open for new team members.

Basically percentages prioritize internal fairness over team growth.

[zbynekwinkler]

Would it make sense to have percentages capped by dollar amounts?

[mvdkleijn]

Would it make sense to have percentages capped by dollar amounts?

Yes, but.. that would mean that anyone wanting more that $ 0.01 would still have to increase their $ amount. Which in my opinion would kinda defeat the point?

Maybe use percentages capped by the $ amount if the take would be more that X amount? (X possibly being a setting in the team account preferences?)

[MikeFair]

Governing/limiting money going to individual users can be handled by the
user's target funding goals. Using a percentage algorithm is the most
flexible of all the strategies, the payout algorithm can deal with the
actual numbers and ensure folks aren't overpaid. What would also make a
difference here is to enable user's to express multiple levels/targets of
funding for the user. The system can then use that information to maximize
the level of good it can do with the money.

A team's funds would allocate out as follows:
Priority 1) Use the team's incoming funds to first ensure all critical team
members receive their "minimum viable target" level of funding. In this
case users have expressed multiple targets, not just one target (but we can
start with just one). This first pass focuses on ensuring the critical team
members get up to their minimum levels. If the critical team members aren't
already receiving enough money from other sources, then this team's funds
can help make up the difference for those users.

Priority 2) Assuming all critical members have received their minimum
viable funding levels; ensure all core members have received their minimum
viable funding levels. The idea here is that we're bootstrapping the team,
critical members keep the team alive, core members make the team
functional; money is allocated to each group this way to ensure the team
can fulfill on its task. The focus here is on getting everyone core to the
project what they need while preventing imbalances. For instance, if one
member of the team is receiving enough money from other projects to provide
for that members' minimum viable funding, then this teams funds would be
better used for those members who aren't receiving that level of funding.
This first phase is all about getting all the people identified as core to
the project up to a minimum viable living "take".

Priority 3) After all the core team members have received their bare
minimum requirements, then you the system uses a more ordinary strategy to
allocate to other users and teams that the team relies on/supports.

Bear in mind users can be receiving allocations from multiple teams
simultaneously because they are meaningfully participating in multiple
projects. This means that a user's "take" from the system could be coming
from multiple sources.

Chad for instance, is likely going to be on a number of teams, and get
allocated to by many different people. Once Chad has received his minimum
viable amounts, the system can use excess allocations to him to ensure
other critical people are receiving their minimum viable amounts.

Only the payout system, looking at all the allocations in the aggregate,
can see that; assuming the team's express their priorities honestly, the
system can maximize the team's allocation of its funds.

If the funds are being expressed in percentages/priorities, then the payout
algorithm can reallocate the excesses (aka amounts over the targets) to
other users in the system. (e.g. If a user would receive more than their
target, take that user out of the allocation list and redistribute the
excess money to the other people in the list prorata according to
priority/percentage.

If a user hasn't expressly stated a funding goal (which many people likely
haven't/won't), then we can use some kind of an approximating/averaging
algorithm to create a default target for the user. Assuming that algorithm
is any good, most people won't have a problem with that.

This means that all users in the system will have a target, the goal of the
system is to maximize the number of people who reach their targets by
reallocating excesses to other people, there are multiple targets
representing different phases/stages of the user's funding targets, and
these targets will either be the system defined algorithmic answer or the
user's expressly stated target (which likely encourages people to state
their targets).

On Tue, Oct 22, 2013 at 4:19 AM, Martijn [email protected] wrote:

Would it make sense to have percentages capped by dollar amounts?

Yes, but.. that would mean that anyone wanting more that $ 0.01 would
still have to increase their $ amount. Which in my opinion would kinda
defeat the point?

Maybe use percentages capped by the $ amount if the take would be more
that X amount? (X possibly being a setting in the team account preferences?)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1609#issuecomment-26794703
.

[pjz]

I wanted this until I thought about having more than 100 people in a team; percent granularity isn't enough, and also isn't intuitive enough. Instead I suggest 'shares'; the total number of shares in existence is the sum of the number that people allocate for themselves - if everyone gives themselves the same number, the money is evenly split. If everyone gives themselves one share, but one person gives themselves two, that person gets twice as much money as everyone else - because the share pool is diluted by an extra share, each share is worth a little bit less.

[rummik]

+1-ing because I haven't before.

[Changaco]

Closing in favor of #1660.