Handle Checker: Deceased/Dismissed Handles Reserved for 3 Years

[flwyd]

The Ranger status policy doc has been updated so that non-vintage handles of deceased or dismissed Rangers are reserved for three years after the date of dismissal (much as if they'd become inactive). The handle checker should be updated to make it easy to compare against all currently reserved handles (or against all handles if desired). Potential conflicts are currently filtered by entity type, e.g. "active Ranger" or "jargon". This new policy introduces a state where a person's status doesn't change but their handle availability does.

I propose handling this by introducing a new HandleReservation API object and corresponding DB table. Fields would be something like id, handle, handle_type, start_date, end_date, person_id. The handle_type field would be an enum with values including vintage_person, nonvintage_person, twii_person, brc_term, ranger_term, radio_jargon. The person_id field would be optional, not present for things like jargon and TWII VIPs. For active and vintage Rangers, radio jargon, etc. the end_date would be some "infinity" value like the year 9999. For VIPs whose callsign appears in The Way It Is (TWII), the end_date would be three years after we do a TWII update, and then bumped another year if they're in next year's TWII. For jargon and terminology which gets retired we can change the end_date from "infinity to "three years from now." (Say, for example, that Moscow changes its name to Milan in 2021. We could set that handle's reservation to end in 2024 and then a mid-decade new volunteer could become Ranger Moscow.)

Ranger handle changes that currently happen (e.g. assigning a handle to a PNV, bonked Alphas, marking someone vintage…) could automatically update this table, but there would also be a management UI so that VCs could update TWII names, work with Council on non-TWII terms that shouldn't be handles, etc. Maybe the HandleReservation should have a reason field as well so special cases can be documented, e.g. "Reserved by Council decision on 2/29/2024." This would provide clearer transparency on what handles are reserved and why, and let VCs manage the change process without requiring code changes.

[flwyd]

@srabraham is interested in this.

[srabraham]

@mikeburg do you have any thoughts/recommended tweaks on this before I start digging into it?

[mikeburg]

So a few thoughts here on implementing this -

1. The admin interface ideally should live under Admin > Edit Records. (At some point we really should investigate cleaning up the Admin menu, it's getting damn crowded and unruly both in terms of size and the various roles which may access it -- it's not exclusively for Admin role holders.). For now, restrict the interface to Admin role holders even though this is a VC tool.

2. I wouldn't bother populating the handle table with vintage callsigns (the person table already tracks this) or cross link with the person table. The important thing is the HandleController to return the correct list of terms & handle. This can be done thru a union of the appropriate callsigns pulled from the person table and the new handle/terms table, like it happens now except the handle table is hard coded and not database based. The less syncing we have to do between tables, the less error prone it will be.

3. Three additional types are needed: deceased_person, dismissed_person and slur. The deceased type is for individuals who have passed on. The policy is to not recycle the handle for 3 years after the person's passing as a sign of respect and give time to the department to grieve and let go. Dismissed is for individuals who have been let go from the department and the handle should never be reused - OR - the person was "pre-bonked" (applicants who we don't want to continue through the PNV program and who should never reapply due to serious personality issues or legal concerns). Note: most pre-bonks' handles are released after the event has ended, however, a few currently do exist where the handle should not be recycled for various reasons.

To handle dismissed on the backend, have the end_date set to now() + 3 years in the before save callback if the end_date is blank.

Slur is for the obvious - a term which may be considered a slur and should never be assigned as a handle. While the current crop of VCs can vet most American & Australian cultural slurs, we deal with many international applicants. We need to track slur terms applicants may attempt to use either intentionally (a slur in their own culture, and find it "funny" to use) or unintentionally (both the VCs and/or applicant is lacking in awareness of the term's origins). Either way, the term should be alerted to the VCs since it may be considered harmful by participants and we burn social capital as a result if the handle is accidentally assigned.

4. To represent a permanent entry in the table, the end_date could be null than an arbitrary number. Might be easier to deal with on the front end to show what has an expiry date, and what is permanent.

5. Don't forget to add an expiry button to clean up the table.

6. A Bulk Uploader feature is critical. The TWII VIPs change from year to year, and the last thing we want to do is annoy and drive the VCs crazy by requiring them to manually enter the handles one at a time. The Bulk Uploader should have an options lists for the type being uploaded (defaulted to the TWII option), check for duplicates, and have a verification & review step before committing the upload. See the other Bulk Uploader interfaces for examples. Bonus points if you can add an optional end date field (e.g., "callsign,end date" -> "hubcap,2023/12/31")

7. For now, keep the reason column as a one line string (aka varchar(255)), and provide a text field (not textarea) to edit. This can help keep the handle wrangling interface simple, and not overload the VCs with info. Last event, we ended up processing 300+ applicants each with 5 different callsign options. The callsign processing time averages around 3 to 5 minutes per applicant. The process includes checks for existing conflicts, simulates understandability over the radio (place hand over mouth and speak the callsign -- can you understand it? does it sound like another callsign?), minor research to see if the proposed handle is culturally problematic, and writing up a message to the applicant if all 5 proposed callsigns are an issue.

8. Keep both the term's original entered value, and a normalized term (i.e., strip spaces, quotes, and other non-alphanumeric characters -- see Person:normalizeCallsign). Use the normalized term to check for duplicates.

[srabraham]

Status update:

• There's now a functional handle reservation admin page, and it creates reservations that show up in the handle checker page
• There is not a bulk upload action yet. That's the big todo remaining for me (along with some smaller TODOs in the code)
• We'll need to correctly move over slurs, jargon, TWII terms, etc. from being hardcoded to being in the new table. This will require coordination with Frankenstein/VCs https://github.com/burningmantech/ranger-clubhouse-web/pull/1559#issuecomment-1397852812
• We'll need to get someone to know that dismissed and deceased callsigns must be entered into the handle reservation page

more to come

[mikeburg]

All goals have been met. Closing out (again).