Sunset past contributors: Decay member take each week after x weeks of non-activity.

[pjc]

In this interview between @whit537 and @tgeller, Chad mentions his frustration with two former team members who don't contribute much anymore but haven't lowered their take.

Having a feature that sunsets the member take after x weeks of non-activity is a non-confrontational way of dealing with issues like this. Collaborator relationships could go sour needlessly if this issue has to be handled manually - not to mention the only option available is the nuclear one of removing the team member altogether the use of which could lower trust in the team lead.

This feature would serve the same purpose as throttling the take of new members but at the opposite end of the collaboration period.

[chadwhitacre]

Here's the video queued up:

https://www.youtube.com/watch?v=9q4QBU97_1U#t=34m59s

[chadwhitacre]

I want it to be soft enough that people don't feel anxious or threatened by it, but it would be great to have something to alleviate the burden on managers to chase people down who have drifted away. They've drifted away! Who wants to chase them down, especially over this? It's like racing out of a restaurant after someone that forget to pay their bill or something.

[pjc]

I agree with it needing to be soft. The 4 week wait and then halving each week is my gut feel but opinions can vary of course.

My other concern is that some contributors may not do git commits - e.g. a big project with a full time PR person.

[chadwhitacre]

How do we define "activity"? Visiting the Members page and maybe clicking a button. I expect @pjz to write a script to automate that (he's already automating his interaction with the take system). The more aggressive the sunsetting, the more we drive people towards scripted pushback. I'm thinking four weeks is too aggressive. I'm thinking more like three months or even six. Likewise, rather than halving, I think we should decay slowly at first and maybe accelerate.

[chadwhitacre]

@pjc Right, we're on the same page. :-)

[chadwhitacre]

The other thing to note is that we have zero email notifications right now. This whole thing could turn out to be a non-issue if we have weekly emails reminding people of what they're taking from where.

[pjc]

Off topic: Can I help with writing the mailers?

At Supportbee I've been doing a lot of those (we do email support after all). Might be a good angle for me to start collaborating on Gittip.

P.S. Pretty damn impressive that Gittip got to where it is without email notifications...

[chadwhitacre]

@pjc Sure! We have a PR going at #1287. Needs tests and wireup w/ Mandrill.

[pjz]

So one way to do this would be to have someone else do a checkin for you; consider a manual 'endorse' button next to each member's name on all group pages. Members aren't allowed to endorse themselves, but any other members are allowed to do so. Wire it up to watch git commits, the '!m' bot, maybe even just plain chats in the IRC channel, and most endorses will happen automatically. Outliers can be handled by manual endorsement. It doesn't necessarily mesh well with the 'Kids Eat First' thing, but does give potentially more data (# of weeks endorsed?) that could be factored into the distribution weighing.

[MikeFair]

+1

Admittedly I haven't looked into the take system yet. I'm assuming that
somehow contributors self identify and self prescribe somehow. Which is
clearly one way of handling teams. Then setting a "half-life" /renewal
requirement on participation deals with the no longer active participant
problem. (The model also implictly dictates/enforces the policy/assumption
that only currently active participants (by some definiton of active)
should get a piece of the current take.)

There are two things this is related to 1) this is exactly the kind of
rules surrounding the whole point behind creating a distributed fund
system. This opt-in/decay out system is one way to run funding a team; so
the concept of a fund here would be that some piece of code creates the
results that represents this logic and publishes them in a file (I like
ATOM or RSS, but anything could be used). Contributors (tippers) then have
subscribed to this file as part of their contributions; the system
downloads these opinions and then distributes their payouts accordingly. I
bring this up here because using funds in this way gives flexibility to
trying out different pieces of logic. There are other ways to formulate
allocating to team members; each can be a different fund; we don't need to
lock ourselves in to a one-size-only strategy.

2. treating this as a "fund implementation" decision and separating the
   apportionment logic into a codebase that's totally separate from the GitTip
   core code keeps the concerns separated (just like moving the payday code
   into its own project separates that concern from the community web UI code).

3. What do you guys think about some contributor takes decaying more slowly
   than others? For instance I was thinking that the number of mentions on !m
   bot might soldify the receiver's longevity in the system more (that would
   go for both the giver of the !m and the receiver). Maybe each the first !m
   in a given week adds a day and each subsequent adds an hour; or something
   else but the idea is to continue funding people the community/team believes
   it's important to continue funding.

Mike
On Oct 15, 2013 1:33 PM, "Peter-Jan Celis" [email protected] wrote:

Off topic: Can I help with writing the mailers?

At Supportbee I've been doing a lot of those (we do email support after
all). Might be a good angle for me to start collaborating on Gittip.

P.S. Pretty damn impressive that Gittip got to where it is without email
notifications...

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

[seanlinsley]

I would suggest against having overly specific methods of determining take. Particularly, I don't think !m mentions should be included as that depends on using Botbot's IRC bot.

[rummik]

@daxter Technically, any one of us could write something that catches !m. There's dozens of IRC libraries (I'm writing one for a few things), and prebuilt bots (@clone1018 is working on one). So it doesn't really need to rely on BotBot

[seanlinsley]

But it does need to rely on IRC. If Gittip is built for more than just the tech crowd, you can't make that type of assumption. Even then, not every OSS team uses IRC.

[rummik]

I was assuming the possible bot would mainly be for Team Gittip use mainly? Technically, not every team is going to use GitHub either. Seems like it should be an opt-in feature, and also in the API

[pjc]

1. I agree that rules like this could be optional 'contracts' that the team lead can select. If the entire economy is going to run on Gittip, there will be a need for different collaboration specifics.
2. Note that the specific rule we are discussing implies, philosophically speaking, a move against absentee ownership i.e. towards a more leftist interpretation of property rights. (A Gittip take is not 'pure' equity because you can not trade it independently of its owner, but it is what I call 'synthetic equity' where people trade their skills into recurring payments not tied directly to input.)

[pjz]

@daxter sorry if I was unclear, when I said 'make a manual endorse button' I meant make a button on a webpage probably with an API behind it, and when I said 'wire it up' to various things, I meant that groups who were using gittip could themselves wire up the API behind pressing the button to whatever form of interaction they think, for their group, is a valid measure of 'activity': IRC comments, tweets, commits to git/svn, comments on tickets... whatever.

[pjz]

Oh, and +1 for factoring take method out of gittip and into some third-party place; it seems a good idea to let each group determine how to split the take, though gittip should of course offer some default methods.

[Changaco]

Closing in favor of #1660.