Dear Steve: It sounds like the feedback you've received falls into a couple of categories:
1) Some minor tweaks, which you have responded to or are seeking more input on. Below the dashed line I have a couple of tweak/questions of my own. 2) A concern that the responsibilities you have described might better fit a delegated team than the current structure. In dealing with this concern, it sounds like you have two options. You can either try and split things into two parts. You can describe what you're doing now, and what you might want to do in the future. Alternatively, you can simply acknowledge that your description is more focused on an eventual goal. Honestly, I think the most critical success factor for the team is recruiting more people. I'd like to propose a recommendation. For now, focus on recruiting rather than on splitting your responsibilities/description into a now vs future split. Recruit assuming that you will eventually be delegated and that you will have responsibilities substantially similar to those you have outlined. Then say in early February we can revisit the delegation question. (February is probably the earliest slot in ongoing delegation work where we'd be able to bring the project-wide focus for the discussion) At that time we could: 1) Choose not to delegate at that point. If we make that choice it probably would be worth coming up with a split set of responsibilities (current vs future thinking) at that time. 2) Choose to delegate. From my side the biggest question is likely to be whether you have managed to recruit enough people to be responsive in the areas where the project has indicated being responsive is critical. 3) Do a phased delegation. So for example if you're still having trouble recruiting enough people, delegate some of the responsibilities including a significant focus on ongoing recruiting. How does that sound? ---------------------------------------- I have two questions/concerns when I think about your description and compare it to past discussions and the mail I wrote last night: > * In extreme incidents or after repeated harmful behaviour or Code of > Conduct violations, writing reports for relevant teams (e.g. Planet > admins, listmasters, DAM), to summarise relevant incidents along > with analysis and suggested possible courses of action; and my understanding from cambridge is that DAM would prefer not to get recommendations on what to do in such cases. Is DAM happy with the suggested possible courses of action language? Even if not, it's fine to keep if other teams would appreciate that feedback. Under things the team does not do: > * Mediate communications or conversations between individuals; or Particularly in light of the de-escalation need I identified in my mail last night, I'd like to understand better what you mean by mediation. From past discussions it sounds like you definitely don't want to be involved in finding solutions to technical problems. You don't want to be doing the work for example I'm doing working with the elogind maintainers, systemd maintainers and others interested in init system issues. How do you feel about your interest and ability to step in and de-escalate situations? I'd be happy to give examples where that would have been useful in private mail to the team. At this stage, I just want to understand what you are willing/able to do and what you are not interested in. Thanks, --Sam
signature.asc
Description: PGP signature
