Offboarding process

Each good developer we loose is a failure in our systems.

We need offboarding processes to try to understand how we failed.

We can also force failure by incorrectly assuming we have already lost the individual, when the cause was they had other priorities.

inactive doesnt imply disinterested, and shouldnt be reason for rejection.

And not everyone is a coder.

https://github.com/coala/coala/issues/3645 is the most relevant background for forcing offboarding.

The reason was the assignee drop-down in GitHub was too slow at loading the long list of members. Removing people who have never contributed might sound like the easy solution, but it fails when we dont know when they were invited, and is very counter-productive if it is done near any time near an offline workshow being held, or done from October/November through to about March as that covers the Google Code-in & Google Summer of Code induction period.

The newcomer gamification process should give us a better set of data to work with, including 'first seen' date.

No files, tests, or implementation entry points are identified. Start by reviewing issue #3645 and the newcomer gamification process referenced here, then clarify the intended offboarding workflow and its success criteria before locating project changes.

Written by the indexing model from the issue text.