Allow receivers to communicate with donors (in mass/anonymous way)

[rcross]

I understand that part of the philosophy of gittip to keep donations/gifts anonymous. However, I think it would be really helpful to allow receivers to communicate to their donors. This allows for simple things like providing updates on what the receiver is working on or how they're using the funds or new things. This helps the receiver build more of a following and is often desired by donors to see how their contributions are helping. I think if there was a way to send email updates to your donors in a bulk/anonymous kind of way, rather than one-on-one, this would still hold up the philosophy of gittip and provide the benefits mentioned. This way you're not providing preferential updates or access or whatever to your highest donors (you still don't know who's giving what). You could also allow non-donors to subscribe to updates (i.e. follow a gittip user) for any arbitrary person/team, which could serve as a way of watching someone's activity before gifting to them. Kickstarter and other crowdfunding platforms have indicated how much contact with backers really drives success of projects, and I think similar dynamics would work here. Donors could/should be given the option to opt-out of updates (unfollow) from the people they give to.

[duckinator]

Hey, @rcross! First off, thanks for all the discussion recently, both here and other issues!

We actually discussed this in hilarious amounts of detail during part of the Gittip Retreat, but I'll summarize it here, since I don't think it's really recorded anywhere except somewhere in the depths of ten hours of video.

The bottom line I took away from it is this: we need to let people broadcast to those who are interested, but we shouldn't be the place where they create content. We should avoid reinventing wheels where possible, especially when we can simply pull from the original sources — which are far better at it than we could probably manage.

We want to allow them to curate existing content from various sites for content creation and social interaction. Some of the ones that were proposed included GitHub, Bitbucket, Twitter, Youtube, SoundCloud, and RSS feeds (for blogs, otherwise-unsupported services, etc).

Note that by curate, I don't mean blindly dump everything: For potentially-noisier platforms, such as Twitter, we would have it default to only showing stuff they create that contains a certain keyword (on Twitter, Google+, and other social networks, that'd probably be the #gittip hashtag), with an option to disable this filtering.

Also worth note is that @rummik is working on a project called Awful Zen which is explicitly for this sort of aggregation/curation.

The idea that has been discussed between her and myself is to eventually have Gittip's profiles incorporate a white-labeled Awful Zen widget. The configuration would be entirely on Gittip's side, and not require them to go to the Awful Zen website at all. This avoids the horrible ugliness that things like Twitter's widgets unleash upon the world, while allowing us to not add massive things to Gittip's codebase that if they don't need to be.

Hope this clarifies some things, and apologies to everyone for not discussing this as publicly as it probably should have been!

(cc people who, iirc, were interested in this discussion at the Retreat: @whit537 @seanlinsley @clone1018 @abnor @heidigardner @rummik)

[rummik]

Just a note: so far the only functional part of Awful Zen is floating in Zenosphere.js (which I use on my site), but I have plans to start working on the server-side implementation soon, probably not too long after Sails 0.10 is released.

[duckinator]

Another possibility, preferably in addition to the above (and not in place of it), would be the possibility of an opt-in email letting receivers send updates to anyone who opts in to it.

I'd argue that something of that sort would also be best done as a third-party service that Gittip ties into, as well, to keep the core website simpler (this is the same reason we pulled widgets out into a separate project).

[rcross]

@duckinator thanks for the details.

awfulzen could be the answer but looks like its not getting much love. It all sounds good, but I think I'd rather see a mvp approach first. With #89 / #1287, if we could just get an email address, then it should be simple to offer a basic broadcast option (simple plain text/markdown) maybe limit it to ~500 characters so that long updates need to link off to other places (blogs, medium.com, etc). The other option might be to utilize a way to send tweets / github messages and just allow people to post blog links for broadcast.

[rcross]

@duckinator yes, that works too. Are you thinking something like tinyletter.com?

[rcross]

also, its worth mentioning that people could easily post a link to a blog or mailing list thing in their profile description, but I think having something that actually integrates with gittip would be about 1000x more effective. re-emphasising my point about kickstarter's communication to backers stats.

[duckinator]

I agree that we should try the minimum viable product first, which would be the email approach.

As you said, the problem is that we don't currently have anyone's email addresses. #89 is the main issue for resolving that. #1022, #2224, #1124, and possibly others, are currently blocked by the resolution of #89. So if this email thing is done, it should ask for their email should ask for it on Gittip's behalf, and use an API to sign them up for the mailing list. We don't want to ask for it once on Gittip's behalf, then again for the email service (or vice-versa).

I'm not sure tinyletter would work well, because we'd need to use something that provides a rather complex API. We'd want to basically create an individual mailing list for each person, so that if they're flagged as spam, it doesn't flag everyone doing it through Gittip. We also don't want them to set it up through their own account on whatever service we wind up using because it would show the list of people who sign up, and if it's advertised primarily through Gittip, then it would likely at least hint at their list of donors, which we don't want. We'd need to get a list of various services for this kind of thing. (cc: @whit537 since you've looked at mailing list services previously.)

[rcross]

my personal inclination would be just to code something using mandrill or
other email transaction service for the delivery. I can’t really think of
any 3rd party service that would offer something to suit our usecase. i.e.
“we want api access to create 1,000+ mailing lists, with access control
over sending, but restricted access to view/manage the each list's
contacts”

On Wed, Apr 2, 2014 at 8:49 PM, Nik Markwell
<[email protected]javascript:_e(%7B%7D,'cvml','[email protected]');

wrote:

I agree that we should try the minimum viable product first, which would
be the email approach.

As you said, the problem is that we don't currently have anyone's email
addresses. #89 #89 is
the main issue for resolving that. #1022#1022,
#2224 #2224, #1124#1124,
and possibly others, are currently blocked by the resolution of #89#89.
So if this email thing is done, it should ask for their email should ask
for it on Gittip's behalf, and use an API to sign them up for the
mailing list. We don't want to ask for it once on Gittip's behalf, then
again for the email service (or vice-versa).

I'm not sure tinyletter would work well, because we'd need to use
something that provides a rather complex API. We'd want to basically create
an individual mailing list for each person, so that if they're flagged as
spam, it doesn't flag everyone doing it through Gittip. We also don't
want them to set it up through their own account on whatever service we
wind up using because it would show the list of people who sign up, and if
it's advertised primarily through Gittip, then it would likely at least
hint at their list of donors, which we don't want. We'd need to get a list
of various services for this kind of thing. (cc: @whit537https://github.com/whit537since you've looked at mailing list services previously.)

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

[Changaco]

Closing in favor of #2521.