Feature #9529

Agree on a process to store information about and ping past PayPal donors

Added by intrigeri 2015-06-04 08:45:01 . Updated 2016-11-03 16:32:05 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Fundraising
Target version:
Tails_2.7
Start date:
2015-06-04
Due date:
% Done:

100%

Feature Branch:
Type of work:
Contributors documentation
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Quite some people send us money via PayPal, and as a result we have a list of email addresses. Shall we use this list for targeted communication, e.g. sending them a yearly email suggesting to donate again? This could be done at the same time as we’re doing a fundraising campaign announced on our website, that explains what are our plans for next year (or so).

Implementation-wise (that’s not exactly what this ticket about, but details may matter to make a decision here):

  • one should probably make sure to not spam people who have set up a recurring donation;
  • IMO the first time we send this email, we should make it clear that it’s a one-time thing, and propose people to opt-in for receiving similar messages in the future; and then we need to keep track of who has not opted-in to avoid spamming them again, while still being able to email new donors.
  • Where should we store these lists? Is the fundraising repo, ok?
  • We should be able to track who we wrote already and not bother people more than necessary.
  • We should allow people to opt-out.

Subtasks

History

#1 Updated by sajolida 2015-06-06 10:16:28

  • related to Feature #9538: Do a fundraising campaign at the beginning of 2015 added

#2 Updated by sajolida 2015-06-06 10:20:25

Maybe you meant /doing a fundraising announcement on our website/ instead of /doing a fundraiser announced on our website/.

I think we should do yearly fundraising campaigns at the end of the year in which we advertise our plans for the next year. We could ping those people by then. I created Feature #9538 for this year.

I’m fine with the modalities that you propose.

But maybe we could replace all these with some simpler. We could do one thing only: “always send our call for donations to people who donated since the previous call for donations”. So if people donate every year, they’ll be updated with our plans yearly. And if people donated only once, they’ll receive only one email from us.

#3 Updated by intrigeri 2015-06-06 12:35:08

  • Description updated

#4 Updated by intrigeri 2015-06-06 12:36:25

> Maybe you meant /doing a fundraising announcement on our website/ instead of /doing a fundraiser announced on our website/.

Absolutely, fixed.

> But maybe we could replace all these with some simpler. We could do one thing only: “always send our call for donations to people who donated since the previous call for donations”. So if people donate every year, they’ll be updated with our plans yearly. And if people donated only once, they’ll receive only one email from us.

Sounds good enough for the donors, and less work for us.

#5 Updated by intrigeri 2015-07-06 13:38:06

  • Assignee deleted (None)
  • Type of work changed from Discuss to Research

Report from the monthly meeting:

"Some of us found it important to have an opt-out mechanism.
u. volunteered to maintain the opt-out information, so next steps are:

1. decide if/how MoC can have access to these opt-out info
2. if “we” find a way to do that, then implement it; otherwise, get
back to “do we really need opt-out”?

… and intrigeri (with his -accounting@ hat on) is OK with taking the
opt-out info into account when “spamming” the rest of the donors.

Some concerns were raised about how that information was managed.
Learning that it was managed under the -accounting@ security policy
satisfied the people who raised these concerns."

Perhaps creating a subtask for the next steps would help.

#6 Updated by sajolida 2015-07-07 00:23:38

Sorry I missed the meeting yesterday. What do you mean by opt-out here? In #note-2 I was proposing to ping people only once (unless they donate again). This would remove the need for opt-out except for regular donors. Are you discussing here an opt-out mechanism for regular donors only?

#7 Updated by intrigeri 2015-07-07 01:26:46

> Sorry I missed the meeting yesterday. What do you mean by opt-out here?

Allowing donors to state that they don’t want to receive any such email from us anymore, even if they donate again.

> In #note-2 I was proposing to ping people only once (unless they donate again). This would remove the need for opt-out except for regular donors. Are you discussing here an opt-out mechanism for regular donors only?

Yes, since indeed people who don’t donate again won’t get emailed again.

#8 Updated by sajolida 2015-07-08 11:03:28

Thanks for the clarification.

#9 Updated by Anonymous 2015-10-14 14:09:12

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

#10 Updated by sajolida 2015-11-27 02:55:37

#11 Updated by sajolida 2015-11-27 02:55:46

  • related to deleted (Feature #9538: Do a fundraising campaign at the beginning of 2015)

#12 Updated by sajolida 2016-08-25 11:14:39

  • Subject changed from Ping PayPal donors regularly? to Ping past PayPal donors
  • Assignee set to sajolida

Making this as part of the upcoming donation campaign. First step would be to list donors in 2015 and 2016 and store them somewhere u can access them.

#13 Updated by sajolida 2016-08-25 11:16:47

#14 Updated by sajolida 2016-08-25 11:16:51

#15 Updated by sajolida 2016-08-25 11:26:45

  • blocked by #11724 added

#16 Updated by sajolida 2016-08-25 11:36:45

  • Subject changed from Ping past PayPal donors to Agree on a process to store information about and ping past PayPal donors
  • Description updated
  • Assignee deleted (sajolida)
  • Target version set to Tails_2.6
  • Type of work changed from Research to Discuss

#18 Updated by sajolida 2016-08-25 11:37:13

  • blocks deleted (#11724)

#19 Updated by sajolida 2016-08-25 11:37:22

  • blocks Feature #10368: Send an email to people who donated last year added

#21 Updated by anonym 2016-09-20 16:53:53

  • Target version changed from Tails_2.6 to Tails_2.7

#22 Updated by Anonymous 2016-09-26 07:52:10

  • Assignee set to sajolida

#24 Updated by sajolida 2016-09-28 11:36:07

We agreed on a process. We’re now waiting for a Git repo and an email address.

#25 Updated by sajolida 2016-10-03 17:32:39

  • Assignee deleted (sajolida)
  • QA Check set to Ready for QA

I can access the Git repo.

u: Can you check that the alias is working and that you can access the Git repo?

#26 Updated by intrigeri 2016-10-04 07:09:34

> u: Can you check that the alias is working and that you can access the Git repo?

I have access to the Git repo but..

… and that’s it’s a git-remote-gcrypt one (that was the plan, right?).

…I don’t think it’s a git-remote-gcrypt one but maybe i missed something?

#27 Updated by Anonymous 2016-10-06 12:00:07

  • Assignee set to intrigeri
  • QA Check changed from Ready for QA to Info Needed

The forwarding address works.

#28 Updated by sajolida 2016-10-06 23:22:11

My request to tails-sysadmins was “Could you create a git-remote-gcrypt repository named ‘tails-donors’?”

#29 Updated by sajolida 2016-10-06 23:23:11

But actually this was not explicitly decided in the thread “where to store emails from donors who opt-out” where I ask the question but is left unanswered. I won’t work more on this myself.

#30 Updated by intrigeri 2016-10-07 16:46:30

> My request to tails-sysadmins was “Could you create a git-remote-gcrypt repository named ‘tails-donors’?”

All empty created Git repos look the same from sysadmins perspective. It’s you, as the user, who needs to initialize it using git-remote-gcrypt.

#31 Updated by intrigeri 2016-10-07 16:49:15

  • Assignee deleted (intrigeri)

> But actually this was not explicitly decided in the thread “where to store emails from donors who opt-out” where I ask the question but is left unanswered.

I’m sorry I postponed reading that thread until a decision was made and it was too late. For the record, I have serious concerns with storing this data in cleartext on a server we don’t control, but since I’ve missed the discussion about it, and you seem to not share my concerns, I won’t bother you about it.

> I won’t work more on this myself.

OK. So reassigning to u because I don’t know why it was reassigned to me. If I’m supposed to do something specific, please let me know.

#32 Updated by sajolida 2016-10-14 00:18:47

  • blocked by deleted (Feature #10368: Send an email to people who donated last year)

#33 Updated by Anonymous 2016-11-01 16:00:01

  • Assignee set to intrigeri
  • Type of work changed from Discuss to Contributors documentation

intrigeri wrote:
> > My request to tails-sysadmins was “Could you create a git-remote-gcrypt repository named ‘tails-donors’?”
>
> All empty created Git repos look the same from sysadmins perspective. It’s you, as the user, who needs to initialize it using git-remote-gcrypt.

I see. So, git-remote-gcrypt does not even have a manpage, but it has a README: https://git.spwhitton.name/?p=git-remote-gcrypt.git;a=blob_plain;f=README.rst;hb=HEAD - which I’ve read and spent already over an hour on. For nothing. I’m unable to make the first push to the repository in order to retrieve the gcrypt-id.

So either somebody who did that before initializes the repository or documents how to do so hint?. Otherwise, I’m afraid, this feels a bit like I’m loosing lots of precious time while getting quite frustrated. So could you, intrigeri, or anonym, eventually document how to do it properly? I’m sending you in a private note what i did.

#35 Updated by intrigeri 2016-11-02 08:32:16

  • Assignee deleted (intrigeri)
  • % Done changed from 10 to 20
  • QA Check deleted (Info Needed)

I’ve tried that:

$ git clone gcrypt::tails@git-tails.immerda.ch:donors.git && cd donors
$ git config remote.origin.gcrypt.participants "GPG KEY IDS"
$ cp ~/tails/fundraising/README .
$ editor README
$ git add README
$ git commit -m 'Initial commit.'
$ git push -f origin master
gcrypt: Repository not found: tails@git-tails.immerda.ch:donors.git
gcrypt: ..but repository ID is set. Aborting.

⇒ it seems that git-remote-gcrypt won’t dare overwriting an existing repo that already has unencrypted content. I guess it makes sense to avoid data loss, but in our case it’s annoying. So I’ve temporarily patched my /usr/bin/git-remote-gcrypt to not return 1 in this case (line 520 on sid), and then git push -f origin master worked.

So you should now be able to clone this repo from scratch, and add whatever data you want in there :)

#36 Updated by Anonymous 2016-11-02 09:19:24

  • Deliverable for set to Hole in the Roof

Hi,

thanks. However, I still wonder what sort of unencrypted content that could have been, because I at least did not manage to push anything there.

#37 Updated by Anonymous 2016-11-02 09:21:12

  • Deliverable for deleted (Hole in the Roof)

#39 Updated by Anonymous 2016-11-02 15:44:18

  • Status changed from In Progress to Resolved
  • Assignee deleted ()
  • % Done changed from 20 to 100

It works now. Thanks again!

#40 Updated by intrigeri 2016-11-02 18:26:23

Wasn’t this ticket also tracking adding said info to the repo?

#41 Updated by sajolida 2016-11-03 16:32:05

I could clone the repo (and so I added some info in there).

> Wasn’t this ticket also tracking adding said info to the repo?

Since past donors can ping us about this at any time, we would have no
way of knowing when the task is completed.

#42 Updated by intrigeri 2017-08-30 10:04:33

  • related to #14530 added