Jay,
Thanks for sending this. Some comments below. I've also sent
you a PR to convert the tables to Markdown, which would
make this rather easier to read.
> 6. To deliver a toolchain that is up-to-date and well regarded by users.
This seems in conflict with "evidence-led". Suppose the toolchain
was well-regarded by users but empirically less efficient than
other toolchains.
> Sponsors, in addition to supporting the IETF for the value it
> delivers, are also increasingly concerned about how the organisations
> they sponsor operate, how they treat their volunteers and staff and
> what opportunities they provide for a diverse range of new
> participants. To be able to explain this, we need to document the
> participant journey, a map of the different stages of participation
> (e.g. newcomer, leadership), at what stages people start their
> participation in the IETF, how they transition between them and at
> what stages they end their participation.
There seems to be an implicit assumption here that people should
have a "career arc" in IETF that starts with newcomer and
ends with leadership, but I don't think that's obviously
true. Many of our most valuable contributors have never served
in leadership and some of them do lots of reviewing but not
a lot of RFC writing.
> With particular regard to the services that are provided to
> participants by the LLC, a culture has built up where decisions are
> taken more on the basis of opinion and debate than evidence. For
> example, someone has a good idea that we should provide X for
> participants and rather than ask participants if they want X, how they
> already obtain it and if it is a priority for them, a debate takes
> place on the merits of us providing it or not. Sometimes this debate
> results in stalemate and issues get put into the “too hard” basket as
> a result.
>
> We need to shift from this to a culture where data is the starting
> point for identifying what needs to change and why and what the impact
> will be. As the transformation says, we need to shift people from
> lining up next to people with the same opinions and standing opposite
> those who disagree, to lining up together facing the data and working
> together to interpret it.
>
> We already have some data available, such as stats on meeting
> attendees and the post-meeting survey, but making this cultural change
> requires much more data. For example, there is a big set of questions
> on non-participation and barriers to participation which are crucial
> to providing better service to the community overall. Obtaining this
> data will require a wide ranging plan backed up with a major programme
> of surveys and technical analysis..
Well, maybe. I certainly do think that data-driven decision
making is important, but in my experience it is often
infeasibly expensive to make one's decisions based entirely
on data. In many cases, the cost of gathering the data to
make a decision whether to implement a feature far exceeds the
cost of implementing the feature. This can be necessary
in cases where the feature might have large negative
impacts, but generally when the cost is just the feature
itself, this is not true. Good product management is about
judgement that is informed by data, not by replacing judgement
with data, as this sort of suggests.
> | 15 | Lack of clarity on why we need additional income, how much and in what form |
Perhaps this should be framed in a less loaded way in terms
of lack of clarity on how much income is needed. If it's unclear,
perhaps we need *less* income (though I doubt that is true).
> Running a cycle of three global meetings per year is a difficult and
> expensive task, and one that is going to get harder because of four
> growing issues.
This seems to be a list of three issues (1) meeting requirements (2)
carbon and (3) COVID
-Ekr
Thanks for sending this. Some comments below. I've also sent
you a PR to convert the tables to Markdown, which would
make this rather easier to read.
> 6. To deliver a toolchain that is up-to-date and well regarded by users.
This seems in conflict with "evidence-led". Suppose the toolchain
was well-regarded by users but empirically less efficient than
other toolchains.
> Sponsors, in addition to supporting the IETF for the value it
> delivers, are also increasingly concerned about how the organisations
> they sponsor operate, how they treat their volunteers and staff and
> what opportunities they provide for a diverse range of new
> participants. To be able to explain this, we need to document the
> participant journey, a map of the different stages of participation
> (e.g. newcomer, leadership), at what stages people start their
> participation in the IETF, how they transition between them and at
> what stages they end their participation.
There seems to be an implicit assumption here that people should
have a "career arc" in IETF that starts with newcomer and
ends with leadership, but I don't think that's obviously
true. Many of our most valuable contributors have never served
in leadership and some of them do lots of reviewing but not
a lot of RFC writing.
> With particular regard to the services that are provided to
> participants by the LLC, a culture has built up where decisions are
> taken more on the basis of opinion and debate than evidence. For
> example, someone has a good idea that we should provide X for
> participants and rather than ask participants if they want X, how they
> already obtain it and if it is a priority for them, a debate takes
> place on the merits of us providing it or not. Sometimes this debate
> results in stalemate and issues get put into the “too hard” basket as
> a result.
>
> We need to shift from this to a culture where data is the starting
> point for identifying what needs to change and why and what the impact
> will be. As the transformation says, we need to shift people from
> lining up next to people with the same opinions and standing opposite
> those who disagree, to lining up together facing the data and working
> together to interpret it.
>
> We already have some data available, such as stats on meeting
> attendees and the post-meeting survey, but making this cultural change
> requires much more data. For example, there is a big set of questions
> on non-participation and barriers to participation which are crucial
> to providing better service to the community overall. Obtaining this
> data will require a wide ranging plan backed up with a major programme
> of surveys and technical analysis..
Well, maybe. I certainly do think that data-driven decision
making is important, but in my experience it is often
infeasibly expensive to make one's decisions based entirely
on data. In many cases, the cost of gathering the data to
make a decision whether to implement a feature far exceeds the
cost of implementing the feature. This can be necessary
in cases where the feature might have large negative
impacts, but generally when the cost is just the feature
itself, this is not true. Good product management is about
judgement that is informed by data, not by replacing judgement
with data, as this sort of suggests.
> | 15 | Lack of clarity on why we need additional income, how much and in what form |
Perhaps this should be framed in a less loaded way in terms
of lack of clarity on how much income is needed. If it's unclear,
perhaps we need *less* income (though I doubt that is true).
> Running a cycle of three global meetings per year is a difficult and
> expensive task, and one that is going to get harder because of four
> growing issues.
This seems to be a list of three issues (1) meeting requirements (2)
carbon and (3) COVID
-Ekr
On Thu, May 28, 2020 at 9:35 PM Jay Daley <jay@xxxxxxxxx> wrote:
All except for three of the issues raised in response to feedback are now addressed by a revised version. This includes major rewrites of a number of areas (tools, engagement), a new linkages section to address a set of related issues, and multiple other changes.
You can either read the whole thing in one go
https://github.com/ietf-llc/strategy-2020-consultation/blob/latest-updates-from-consultation/DRAFT%20Strategic%20Plan%202020.md
or you can read the individual commits, each of which tackles a related set of issues
https://github.com/ietf-llc/strategy-2020-consultation/commits/latest-updates-from-consultation
I would be grateful if those of you who provided feedback could let me know if these rewrites address your feedback or if more work is needed, and I welcome new feedback from anyone.
For the remaining three issues
1. https://github.com/ietf-llc/strategy-2020-consultation/issues/11 "Needs to explicitly reference the mission statements of IETF/IRTF/IAB"
The submitter has agreed with me that this is handled by other changes
2. https://github.com/ietf-llc/strategy-2020-consultation/issues/2 "Emphasis on accessibility for non-native english speakers needed"
Is out of scope for the LLC to decide on this and to do it without clear community guidance
3. https://github.com/ietf-llc/strategy-2020-consultation/issues/3 "No reference to support being developed for community members who promote the IETF in different communities"
We have done this some time ago but not clear if that was off our own back (and therefore out of scope) or following community lead. Checking.
thanks
Jay
--
Jay Daley
IETF Executive Director
jay@xxxxxxxx
