Seems like the communication with MIRI can be a frustrating experience.
What is the standard solution to this kind of problem? You need some kind of database of ongoing tasks. When something happens, for example Viktoria applies for a job, you create a new ticket. (Ticket type = job application. Title = “Viktoria applies for Software Engineer role”. Created = 2020-02-26. Assigned to = Buck. Status = evaluating the applicant.)
Then you create some queries, for example “Open job applications”. There should be a person responsible for checking this query once in a while. If you move Buck to a different role, you check his open tickets and assign them to someone else. There could be some alarm queries such as “Open tickets where no update was made during the last month”. There should be a person responsible for checking this, too.
Dear people in MIRI, do you have anything resembling this? Could you please show Viktoria her ticket?
*
The parts about metahonesty etc. seem to me like red hering. I suspect that most people in MIRI simply never had a job outside of academia or a non-profit, and as a result they are quite unfamiliar with how to do things efficiently and reliably. Incompetence, not malice.
*
The most primitive version of a ticket system would probably be a combination of a shared spreadsheet and a wiki. The wiki would have one page per ticket, the spreadsheet would contain the metadata. For example, the spreadsheet would have tabs “Job Applications (open)” and “Job Applications (closed)”; the first one would have columns like “Created”, “Last Update”, “Applicant Name”, “Role”, “Assigned To”, “Current Status”, “Wiki Page”, and the corresponding wiki page would be called like “JOB-001″ and would contain the entire history of what happened.
Dear people in MIRI, do you have anything resembling this?
We did when I was there, and I wouldn’t be surprised if it was still in use. (It was in Asana, iirc.) I don’t think there was a meta-system of “check whether or not people are falling thru the cracks”. When I left and stopped handling one of the inboxes, it got handed to someone else, but I don’t think we ever had targets for things like ‘response time’ or ‘fraction of applicants responded to’ or so on that we checked how well people were doing on. A bunch of people who we didn’t have form responses to, or weren’t quite sure how to evaluate, I think spent a lot of time waiting for replies (or never got them).
[FWIW my sense is that Buck was better than I was at communicating with candidates, and I think the “rejection but here’s how to impress me” is a better response for everyone than “hmm I’m not quite sure what to do with this person, I’ll come back to this later”.]
One problem is that I don’t think keeping the public-facing messaging up-to-date was a priority for anyone, or a lot of things were in ‘maintenance mode’ and only barely getting maintained. Like, we had a MIRIx program, where we would pay for meals/snacks for people to talk about MIRI research; I don’t remember who started it, but I took over the ‘handle requested changes’ function (like if an organizer emailed us to change their email, or get taken off the list, or to get their reimbursement or w/e). But the page looks the same as it did when I left, and I’m pretty sure a lot of those are out of date (I’d be surprised if Tom Everitt is still running events in Canberra, given that he lives in the UK now, for example). It’d probably be good to update the page to reflect the actual level of interest from current-MIRI, but I’m not sure who would think that’s a high-priority thing for them to do (and so probably it wouldn’t seem good taking opportunity cost into account).
If you have the capacity to set up JIRA/whatever and maintain it, yeah, it will work.
But it will not work out of the box. You need to set up the ticket types, define workflows, etc. Later redefine them, if something changes or you find out that the original setup did not work well. Setting up JIRA is a bit complicated and requires some technical skills. You may find out that one member of your team now became a part-time JIRA administrator. For a small organization this may be an unacceptable overhead. On the other hand, incorrectly set up system (workflows that do not correspond to reality) will be a pain to work with.
That is why I offered a poor man’s version that can be set up in an afternoon.
Seems like the communication with MIRI can be a frustrating experience.
What is the standard solution to this kind of problem? You need some kind of database of ongoing tasks. When something happens, for example Viktoria applies for a job, you create a new ticket. (Ticket type = job application. Title = “Viktoria applies for Software Engineer role”. Created = 2020-02-26. Assigned to = Buck. Status = evaluating the applicant.)
Then you create some queries, for example “Open job applications”. There should be a person responsible for checking this query once in a while. If you move Buck to a different role, you check his open tickets and assign them to someone else. There could be some alarm queries such as “Open tickets where no update was made during the last month”. There should be a person responsible for checking this, too.
Dear people in MIRI, do you have anything resembling this? Could you please show Viktoria her ticket?
*
The parts about metahonesty etc. seem to me like red hering. I suspect that most people in MIRI simply never had a job outside of academia or a non-profit, and as a result they are quite unfamiliar with how to do things efficiently and reliably. Incompetence, not malice.
*
The most primitive version of a ticket system would probably be a combination of a shared spreadsheet and a wiki. The wiki would have one page per ticket, the spreadsheet would contain the metadata. For example, the spreadsheet would have tabs “Job Applications (open)” and “Job Applications (closed)”; the first one would have columns like “Created”, “Last Update”, “Applicant Name”, “Role”, “Assigned To”, “Current Status”, “Wiki Page”, and the corresponding wiki page would be called like “JOB-001″ and would contain the entire history of what happened.
We did when I was there, and I wouldn’t be surprised if it was still in use. (It was in Asana, iirc.) I don’t think there was a meta-system of “check whether or not people are falling thru the cracks”. When I left and stopped handling one of the inboxes, it got handed to someone else, but I don’t think we ever had targets for things like ‘response time’ or ‘fraction of applicants responded to’ or so on that we checked how well people were doing on. A bunch of people who we didn’t have form responses to, or weren’t quite sure how to evaluate, I think spent a lot of time waiting for replies (or never got them).
[FWIW my sense is that Buck was better than I was at communicating with candidates, and I think the “rejection but here’s how to impress me” is a better response for everyone than “hmm I’m not quite sure what to do with this person, I’ll come back to this later”.]
One problem is that I don’t think keeping the public-facing messaging up-to-date was a priority for anyone, or a lot of things were in ‘maintenance mode’ and only barely getting maintained. Like, we had a MIRIx program, where we would pay for meals/snacks for people to talk about MIRI research; I don’t remember who started it, but I took over the ‘handle requested changes’ function (like if an organizer emailed us to change their email, or get taken off the list, or to get their reimbursement or w/e). But the page looks the same as it did when I left, and I’m pretty sure a lot of those are out of date (I’d be surprised if Tom Everitt is still running events in Canberra, given that he lives in the UK now, for example). It’d probably be good to update the page to reflect the actual level of interest from current-MIRI, but I’m not sure who would think that’s a high-priority thing for them to do (and so probably it wouldn’t seem good taking opportunity cost into account).
Why not just use JIRA or a free equivalent?
If you have the capacity to set up JIRA/whatever and maintain it, yeah, it will work.
But it will not work out of the box. You need to set up the ticket types, define workflows, etc. Later redefine them, if something changes or you find out that the original setup did not work well. Setting up JIRA is a bit complicated and requires some technical skills. You may find out that one member of your team now became a part-time JIRA administrator. For a small organization this may be an unacceptable overhead. On the other hand, incorrectly set up system (workflows that do not correspond to reality) will be a pain to work with.
That is why I offered a poor man’s version that can be set up in an afternoon.