Plan for dropping dead Linux Counter entries

This page details the steps needed before we drop the dead entries off the Linux Counter's usercounts.

Definition of a dead entry

A dead entry is one that satisfies one of the criteria below:

• Ancient:
  • Has not been accessed for 2 years (730 days)
  • Reminder email sent at least 3 months ago (90 days)
• Uncontactable:
  • All his emails are in state BAD
  • Has not been accessed for 1 year (365 days)

Database content work

There are some dead people that may be salvageable.

• Other known accounts. 1424 users have a BAD main email, and some other email that is not BAD. (953 public, 471 old).
  Suggested action: Set their main email to the non-bad mail and send a reminder. (It is likely that most of them will bounce - many were changes away from uni emails to corporate or service-provider accounts)
• Fixable syntax errors. Some people make mistakes in typing emails that can be corrected (commas in compuserve userids, for instance, or various instances of NOSPAM).
  Suggested action: If using the email as main, fix the error and send a reminder.

There is also a steady leakage back from BAD to OK state for emails; this means that the cronjobs might want to run a last check on the bad-email people before freezing them.
(the cron jobs check 20 BAD records every night - on average about one flips from BAD to OK. Of course, emails that are BAD because of bounces cannot be checked this way)
fwiw, checking BAD entries to SMTP level takes about 5 seconds per entry. Lots of things go to timeout.

Administrative interface work

The admin view of a person needs to have a button for "send reminder".

The admin view needs a function to switch which email is his "main" email.

At the moment, most errors do not have "level" associated with them. Need to re-run the checking script to fill in the "level" field.

Need to have lists generated of all persons that are "fixable".

Need to have a "find frozen account" function, and an "unfreeze" function.

There needs to be a "freeze" script that finds all the people eligible for freezing and freezes them. The first run will be massive; the job will later have to be run from cron.

There needs to be a "rollback" function to deal with abuses, which rolls back the user and/or person and/or machine records to a previous known state.

User interface work

Need to have a function for people to go in with their old, bad email, specify a new one, and be able to take over the old entry. Query: How much do we trust them?

Need to be able to let people usefully specify alternate emails in case one email goes bad. Emails of type "backup".

The reminder email needs to have a URL that one can use to say "hit this URL to say you're still there", which sets the logintime. It would be useful if "reply" could accomplish the same thing.

There should be a "rescue this account" function - perhaps off the login page - where people can update a record with a new address without logging in. A CC mail to the administrator should be enough to ensure that abuses are detected (?).

PR work

I think a gradual draw-down of the user count is a Bad Thing.

I think it would be better to withdraw ALL the candidate "bad ones" in one go, advertising the event widely (which would probably get us some of them back + some new ones - good for us!)

Someone needs to write the web pages explaining what is happening and how to get back your "lost" entry - and to write the advertising hype!
Possible outlets:

• Slashdot
• Linux Today
• Linux World
• Every webzine that has featured the counter....

On the day that we go public, we'd better have some adequate staffing on hand - including the ability to reboot the machine if required, and to fix any obvious problems; we will be inundated with email.