figure out the equation for giving to communities

[chadwhitacre]

A huge value in having community pages (#496) is in being able to give money to that community and then have it divvied up sensibly, automatically. What's going to be our formula for this?

In a sense this is a fund (#449) with an automated allocation. So what's the allocation in this case? Constraints:

• one blanket rule for all communities
• simple to comprehend
• fair in the eyes of both "rock stars" and "yeomen"

How do we generate the list of people? How do we assign weights?

cc: @MikeFair @carsomyr

---

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

[chadwhitacre]

Perhaps we delegate to the most popular funds within a community. In which case, the question becomes: how do we determine which funds are the most popular within a given community? Perhaps, similarly to individual accounts, funds can be tagged with a community by their owners?

Ooooh! Perhaps that's the way that individual accounts are associated with communities as well? Hmmm ...

[chadwhitacre]

So you wouldn't tag yourself as being part of a community. You would tag your funds with this or that community, and then any individual accounts that gave or received money via funds so-tagged would be considered part of that community. I like this line of thinking.

[abnor]

Not tag-profiles, but tag-funds?

[MikeFair]

I think very differently about this.

1. I don't think we're know enough to predict what the right answers here
   are. I believe the answers are going to be "it depends" and so this is
   going to vary somewhat throughout different communities.

The model I like most is that what GT is providing people is a toolkit they
can use to create their own rules for how they'd like to see things and
giving them a way to share those rules with each other.

The rules are encoded in the basket format the GT engine uses to direct
allocations.

People upload baskets to GT or provide a URL where the baskets get pulled
from (presumably this URL runs code to dynamically produce the basket).

We can hilite communities/baskets that are doing interesting things that we
think works well. We also make the basket processing engine that provides
them the ruleset they can use, but we aren't the ones defining the rules
for them. (Though we might create some templates they can use as
guidelines.)

2. This also gets into the question of what is a community exactly and what
   is a project exactly. I say that a commmunity or project doesn't actually
   exist, they are abstract ideas; only people exist.

If there is a community page, unless it is entirely constructed as an
emergent property of other activity on the system than what it really
represents is an concept claimed by the stewards of the page. Do those
stewards always speak for everyone? I say they don't, they speak one
version of the community, perhaps even the majority version, but their
vision/version is not the only one people could be interested in.

For instance let's say Apache had a community page. What do you think it
should mean to give to Apache?
Apache is well known for having many differing opinions internally which
reflects the membership model they've created. That means there are
competing agendas (not meaning thatin a bad way, just clarifying that
there's multiple, sometimes conflicting points of view).

Also something to think about the page itself, did someone set up the
community page or did it get created dynamically? What is someone trying
to express when they give to Apache? Who specifically are they meaning to
support?

I don't think we can say right now. When things are small, only a few
people, creating a single point of view is pretty common, but once we start
scaling up, it gets less possible.

You can certainly do things like the Twitter tag thing to create ad hoc
communities and topics/projects and create dynamic portfolios off of that.

But that's just one algorithm, and that's not the crux of the issue. The
crux of the issue is all about who is ending up with discretion over how
these funds get spent?

I see it working best when there a couple layers of both active decision
makers and algorithmic construction.

Nobody is going to know how it's all going work out so we want both kinds
of expressions happening.

We also can't know what they one true right expression is, though we can
certainly come up with some good ideas they need to change over time, over
cultures, and over different types of communities.

People are smart and can figure out for themselves who they want to give
the discretion to. The best thing we can do is put together charts and
graphs that inform them what the cuurent consequences of their allocation
decisions are and then let them take it from there.

3. Lastly, I don't think it's a feasible long term solution to continue
   with the mental model of that we're each "sending money out there" to "go
   to a community".

The mental model that's going to scale is that we're each "sucking in
community intelligence into our own giving trees" and then using those
ideas for constructing "who to direct our allocations to".

I see it's very much like the difference between how a distributed version
control system like GIT works versus centralized version control like SVN.

In centralized there is this single thing 'out there' called a 'community
tree' and someone has given it a name and location where you can send it
money to be disbursed amongst its members. That's the typical line of
thinking and current mental constricted folks are using.

But that's not how it actually works in real life.

What's actually going on is we've got a whole bunch of people who have this
idea represented by this community name in their head and they each have
their own version of what that community is and who its members are and how
things should work.

This is exactly like distributed version control.
For the most everyone pretty much agrees and there's typically one version
that's considered the master source. But it really is philosophically no
different than anyone else's version, it just coincidently gets used a
whole more.

So the way things work this way for GT is that end users subscribe to a
community basket. There can be many versions of the same community basket
each identified by a different location. The basket they choose is the one
that gets sucked into their master tree and is used to construct their set
of allocations on payday. This happens for each giver. They went around
and subscribed to ideas at where they wanted their money to go. They
likely chose the most popular or most officially recognized basket in most
cases. That basket got constructed according to the algorithm/rules the
steward(s) of that basket used.

In this mental construct, the money never gets sent to the community. The
community publishes an opinion of who they think people ought to send their
money to (technically this "who" might be nested a few nested basket layers
deep but ultimately the basket always resolves to a list of people and
allocation amounts).

People can then subscribe to this community opinion for the GT engine to
use when processing their allocations. This makes everything very clean
and very dynamic because we can always create new baskets to capture new
rules. Groups like Apache can publish multiple baskets which each
individually representative of a consistent point of view for supporting
the Apache community and constrainable in a way that keeps the baskets
focused and relevant.

If everyone who claimed #apache automatically split everything given to
Apache then you'd get a dilution problem as inactive members and
potentially poachers continued to benefit from the Apache public good
will. I say we want to concentrate the directed giving to good stewards
who can then do what they want with it.

If people don't like results, they can subscribe to a different basket.
This way there's no central point of exclusive discretionary control to
dictate exactly how giving to that community gets done. There's simply the
main opinion and if that community should fork, or internally have
disagreememts over how to allocate funds, there can be multiple baskets,
each representing a different point of view on how to get it done.
On Mar 2, 2013 10:30 PM, "Chad Whitacre" [email protected] wrote:

So you wouldn't tag yourself as being part of a community. You would tag
your funds with this or that community, and then any individual accounts
that gave or received money via funds so-tagged would be considered part of
that community. I like this line of thinking.

—
Reply to this email directly or view it on GitHubhttps://github.com/zetaweb/www.gittip.com/issues/696#issuecomment-14342845
.

[chadwhitacre]

s/basket/fund

Eh?

[chadwhitacre]

unless it is entirely constructed as an emergent property of other activity on the system than what it really represents is an concept claimed by the stewards of the page

My thinking is that community pages are the former: "entirely constructed as an emergent property of other activity on the system." Maybe we could even skip the tagging and just use the fund name as the point of overlap. I create a fund named "apache" and it ends up on https://www.gittip.com/for/apache/ along with everyone else's fund named "apache."

[abnor]

Innovative. The only problem is that you get runaway tags like on tumblr #art #donatingtoart #warhol #andywarhol #warholart

Might be a good start though, and you can clean it up later. Would you make it required for each donation or optional?

[MikeFair]

On Mar 3, 2013 1:26 PM, "Chad Whitacre" [email protected] wrote:

unless it is entirely constructed as an emergent property of other
activity on the system than what it really represents is an concept claimed
by the stewards of the page

My thinking is that community pages are the former: "entirely constructed
as an emergent property of other activity on the system." Maybe we could
even skip the tagging and just use the fund name as the point of overlap. I
create a fund named "apache" and it ends up on
https://www.gittip.com/for/apache/ along with everyone else's fund named
"apache."

—

That could work, or at least there are far worse places to start. ;)

Perhaps we even include a tag cloud representing the various destinations
contained in the various funds to give the user a sense of the commonality
between all the funds.

OK I just had two ideas about this thatvcould be pretty cool. To solve for
the multiple names problem we'll need some mechanism for disambiguation and
convergence of multiple labels. Since I'm not so ken on that problem I'm
sure someone else will come up with something brilliant for this.
Wikipedia does a decent enough job of it. This is an area of active GitTip
stewardship I think. A place where people can volunteer to make a
difference in creating pages to aggregate and disambiguate labels in the
system. I think it takes a human intelligence that can read the language
the tags are written in to do that job. Be clear that these people aren't
touching the dynamically generated pages, but they are helping to identify
when the same word(s) is actually talking about two different communities
or when two different words are talking about the same community. I think
that kind of decision gets made really well works using a consensus driven
process. The computer systems can facilitate that process easily (people
can flag funds that they think don't belong for review or tag other funds
that they think belong combined with another family - an editor of some
kind can take it from there).

That's pretty cool actually.

2. We can use the tags and destinations within the fund as kind of like an
   online shopping experience where we're lookijgvto help you find the fund(s)
   you want by checking boxes of things the fund must include or things the
   fund must not include (aka must exclude).

When I first get to Apache I see hundreds of funds and big tag cloud
showing me the prominence of commonality between them all. This
automatically gives me some sense of what's in these things.

Then I click a tag and mark it as include or exclude, perhaps I can set an
approximate weight or a weight relative weight to some other tag that this
tag should have.

This begins the process of reducing the set of funds I see on my screen. I
click another tag, mark it, and that reduces the set again. I keep this
action up until I've reduced the number of funds I am seeing to something
manageable that I can look more closely through.

After which I can then subscribe to one or more of those funds, decide that
no fund represents my point of view and make a new one, or do neither of
those things and revise my search criteria.

That actually sounds workable. Funds are free to be added at any point in
time, the user has a way to cull them from their view, community pages are
emergent from the funds, there is a mechanism for dealing with
disambiguation and aggregation, and while I didn't list it above, the tag
cloud and/or defence map can create a kind of brain map navigation through
the relationships of funds to other funds.

What do you guys think?

[chadwhitacre]

@MikeFair Sounds like we're on the same page. This is a pretty significant engineering effort.

[Changaco]

Closing in favor of #1493.

[chadwhitacre]

Reopening, because some communities will be for trademarked names, and in those cases we should link up to an "official" Gratipay account. I.e., centralized vs. decentralized. This is coming up in conversation with Software Freedom Conservancy re: Git. Python (Python Software Foundation), Django (Django Software Foundation), and jQuery (jQuery Foundation) would be further examples.

[webmaven]

Note that SF Conservancy (like other fiscal sponsorship non profits) is a placeholder for many projects, not just Git: http://sfconservancy.org/members/current/

Other Conservancy projects that already have their own communities on Gratipay include PyPy, Selenium, and Twisted.

I have a strong intuition that making this as easy as possible for fiscal sponsors will have a multiplier effect on the size and activity of the GP ecosystem.

[chadwhitacre]

Closing in light of #3127.

[chadwhitacre]

Heh. Thanks @rohitpaulk. :-)