David,
I prefer the original 60 day proposal over the 30 day notice. Some of the projects listed probably don't have all the most volunteer help (I know ESAPI does not), and addressing some of these things can take longer than 60 days.

Just my $.02,
-kevin
--
Blog: http://off-the-wall-security.blogspot.com/.   | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.

Kevin W. Wall:
Kevin Wall posted:

I prefer the original 60 day proposal over the 30 day notice. Some of the projects listed probably don't have all the most volunteer help (I know ESAPI does not), and addressing some of these things can take longer than 60 days.
Just my $.02,
-kevin

That makes sense. Since I proposed 60 days originally, I obviously don't think 60 days is a terrible number. However, Marcus also has a point - we want to encourage people to not lose momentum. Waiting 60 days for a _first_ reminder may be too long. Perhaps the better approach is to send the very *first* reminder after 30 days of inactivity, and then only send _later_ reminders every 60 days. That way, people who are overwhelmed are unlikely to feel nagged, but people who just got a little busy get their _first_ reminder sooner.

Here's an updated (detailed) proposal, below. Or discuss on: https://github.com/linuxfoundation/cii-best-practices-badge/issues/487

There are a lot of moving parts in this algorithm, but I think it's clear. I just want to make sure that we avoid lots of nagging - the goal is to encourage people, not to bother them. Comments?

--- David A. Wheeler

=============================

1. If we're in a production environment but not the true production system (e.g., the "staging" branch), stop & don't send any emails.
2. Select projects eligible for reminders = in_progress and not recently_lost_badge and not disabled_reminders and inactive and not recently_reminded:
* in_progress = badge_percentage less than 100%.
* recently_lost_badge = lost_passing_at is not null AND less than 30 days ago
* disabled_reminders = flag on project, default false. If true, the project won't receive any reminders.
* inactive = updated_at is 30 days ago or more
* recently_reminded = last_reminder_at is not null AND less than 60 days ago. Notice that if recently_reminded is null (no reminders sent), only the other criteria matter.
3. Prioritize. Sort by the last_reminder_at datetime (use updated_at if last_reminder_at is null), oldest first. Since last_reminder_at gets updated with a newer datetime when we send a message, each email will send will lower its reminder priority - we will _eventually_ cycle through all inactive projects.
4. Send X of the highest-priority (oldest) emails, and for each, reset its last_reminder_at as we send the email.
5. Send a single report message to the LF, providing a list of projects who were given a reminder.

By only sending X messages at a time, we don't look like a spammer, and we limit the damage if there's an error in the code.

I'm not sure how easy will be to index on "last_reminder_at", particularly at the ORM level (which I really want to use because that's portable). That will need investigating. In general I try to _always_ have an index for any anticipated database search or sort, so that we can grow quickly.

David,
You wrote:
> There are a lot of moving parts in this algorithm, but I think it's clear.  I just want to make sure that we avoid lots of nagging - the goal is to encourage people, not to bother them.  Comments?

I see where in step 2 of the algorithm, you already have a check for 'not disabled_reminders'. I was going to suggest that as a profile option, but seems you've already thought of it.

Just mention the ability to disable reminders in the emails you send out and IMO, that will sufficiently address your concerns about nagging.

Also, I'm good with sending out the first notice after 30 days and 60 days thereafter. I think that's a reasonable compromise (although I probably would have just split the difference and made it every 45 days, period, as that would simplify your algorithm).

-kevin
--
Blog: http://off-the-wall-security.blogspot.com/.   | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.