Create role assessment spreadsheet

[cbeams]

From teamleads chat on Jan 23rd:

We need to take stock of the overall roles situation. I'm picturing a spreadsheet that has a row for every role and owner of that role. So there would be just one row for "Ops Team Lead" with @wiz as the owner and there would be N rows for "Bitcoin Node Operator", one for each owner of that role. For roles with multiple owners there a column named "Primary" indicates who among the multiple owners (if any) is designated as the "primary" owner. A column named "Docs" indicates whether the role has documentation. If so, a link is provided, if not, "none" is entered. See 1 and 2 for a refresher on how role documentation is supposed to work. A column named "Bond" contains the amount that owners should be bonded at to hold this role, 0 if it is a non-bonded role. A "Bond Posted" column contains yes or no for bonded roles, and is left blank for non-bonded roles. A "Grade" column contains a value A, B, C, D, F (american grading scale). A notes field contains any information about why the grade was given or anything else that is relevant.

Any bonded contributor who has not paid their bond will be put on notice by their team lead that they'll be removed from the position by the end of Cycle X if they have not paid it.

Any bonded contributor who receives a grade of D or F is put on notice by their team lead that they will be removed from their role by the end of Cycle X, and that in this one-time amnesty, their bond will be refunded in whole. If they make the case that they really wish to keep the role, the team lead has the discretion to "give them another shot", but this should be done only if you really have faith the person will follow through.

Grading should initially be done by team leads for each role owner they oversee, but other team leads may comment on and challenge the given grade if they have different information or a different perspective on the situation.

Note that chronic non-compliance with per-cycle role reporting should probably be an automatic D. This is a basic requirement for all role owners, and failure to do it is a pretty strong indicator they're not taking the role seriously.

All of the above doesn't have be harsh, impersonal or mechanistic; it's just a structure to ensure the right stuff does in fact happen. When in doubt, of course feel free to talk directly with the role owner and ask them how it's going, what they need, whether they're willing and interested to continue, etc.

The team lead will have to assume owership of any roles that has its (primary) owner removed without an immediate replacement. These roles will be in a state of exception, and the team lead won't need to bond themselves into each role they assume (their overall team lead bond can cover it in the meantime), but they should do at least the bare minimum reporting every month and carry out the minimum duties necessary for the role. The incentive will be strong to find new role owners (note that Manfred and I each owned something like 12 and 18 different roles respectively for quite a while until they got better distributed). I'm now running the risk of going into too much detail / planning here, though.

The last thing I can think of that needs to be addressed here is lack of documentation. I think the way to handle roles that don't have documentation is to point the (primary) role owner in question at the links below, tell them to follow convention and write their own role's documentation and submit a PR for it. Role documentation should be lean and mean, really just a few standard sections and a few specific bullet points in most cases. Their team lead should get pinged to review the PR (I'd like to take a look at them too). This exercise should not feel bureaucratic; this documentation defines what must be done to keep things operating smoothly in the DAO. If a role owner doesn't think that's important, then they probably should not hold their role.

Generally, I'm optimistic about this. I think that when people see that management is taking this seriously, they'll take it seriously too. We just need to execute on it. This does NOT need to happen before the call next week, but it would be good if it happens very shortly afterward. Would anyone like to own creating the spreadsheet above? Any feedback or other suggestions?

And @wiz, this process should provide us with plenty of information as to whether changing the bonded role unit factor would be helpful or necessary, but I think it's mostly about injecting the kind of rigor/discipline/accountability that's been missing.

• @wiz to refine the initial spreadsheet at https://docs.google.com/spreadsheets/d/1XWsESTCg_iJ1JTTlHiL10jT60UkfwT6RT5jPESsVHhk/edit#gid=0 (which primarily captures bonding information) to meet the spec laid out above.
• @cbeams to review

[wiz]

@m52go I worked on the spreadsheet for a while but I'm handing it over to you now to finish it

[cbeams]

Closing this issue as dropped along with aborting its parent project. Thanks @wiz and @m52go for the work on the roles spreadsheet. Many things around roles have been cleaned up in the meantime, but we never actually put the spreadsheet to use as originally intended. Sorry for what amounted to busywork.