Stay Home Meet Occasionally Online
charter-ietf-shmoo-02

[Ballot comment]
"Aside from fee structure," could perhaps be "Aside from the fee structure for remote participation",
but this version does resolve the internal inconsistency that had triggered my previous BLOCK.

[Ballot comment]
I agree with Ben's block, I think it should be 3rd item not 4th item that needs discussion on financial aspects.

I also think there might be confusion on where to draw the line between a mostly-online and hybrid meeting.

[Ballot block]
The removal of the "community health"-related work item renders the
qualifier of "Aside from the fourth work item above, discussion of
financial aspects of IETF meetings and changes to RFC 8713 are both
out of scope" inaccurate -- the work item in question is now the
third work item.

[Ballot comment]
  - Meeting planning for mostly online, or “hybrid,” meetings. Meetings that have
    an in-person component but with significantly more remote participants than a
    mostly-in-person meeting need to be planned with community consensus
    guidelines, too. While trade-offs have often been addressed in favor of onsite
    attendees, the IESG and LLC would benefit from having community consensus on
    high-level guidance about the organization of such hybrid meetings, regarding
    such things as the meeting schedule, the meeting length in days, and
    acceptable limitations on the maximum allowed or minimum expected onsite
    attendees, whether and how to schedule and prioritize among onsite activities
    such as side meetings, the terminal room, the code lounge, and others, and
    other scheduling aspects.

Is the "and" before "acceptable limitations" placed as intended?  It seems to imply
that the "acceptable limitations on" clause also applies to the subsequent items
including "whether and how to schedule and prioritize among onsite activities", which
doesn't make much sense to me.

    Specifications of details
  concerning cancellation criteria, meeting technologies, and online meeting
  agenda formats and content are out of scope.  [...]

I think there might be room for some community consensus guidance on good reasons
to cancel a meeting, I acknowledge that such guidance would inherently be
incomplete and the IESG and LLC would always need to be able to exercise
considerable flexibility in adapting to changing circumstances, so leaving the
topic fully out of scope as indicated here may well be the right choice, at
least for now.

[Ballot comment]
All the work items include a sentence about how they are expected to be fulfilled: "with the publication of one or more BCPs", for example.  There is no such indication for the second item.  Is there a reason for that?


Milestones should be included before approval.

[Ballot comment]
I still find the naming/terminology about the different types of meetings to be more confusing that it needs to be:

Currently, the charter references 4 types of meetings: in-person, mostly-in-person, hybrid, fully-online.  I would at least align in-person and mostly-in-person to the same thing, since I believe that they are meant to be referring to the same thing.

It is also not intuitive to me why a mostly-in-person meeting isn't actually also a hybrid meeting.  I.e., calling these mostly-online rather than hybrid may help avoid confusion in the future over what a hybrid meeting represents.

Regards,
Rob

[Ballot comment]
Thanks for addressing my BLOCK.

I suspect that a strong consensus to change the meeting cadence will be elusive, but as the charter has that qualifier it's fine to include it.

[Ballot comment]
I have the same concern as Martin and other ADs about the feasibility of producing an IETF document in the form of BCP describing the high-level principles the IESG and IETF LLC regarding health guidelines.

[Ballot comment]
"Meeting planning for mostly online, or "hybrid" meetings"

- I would suggest changing this to just "Meeting planning for hybrid meetings", since they may apply even if participation isn't mostly online, i.e., strictly greater than 50%.

- I would also change "mostly-in-person" to just "in-person".  In the charter intro, it could clarify that "in-person" meetings have traditionally had some remote-attendence capabilities, but are optimized for in-person participation, and then use "in-person" consistently.

- Should the charter cover providing community guidance about what level of remote participation support is expected/required for "in-person" meetings?

Regarding:

  Meeting planning for meetings where special measures are required to manage
  community health due to venue specific restrictions and/or to comply with any
  local health regulations, e.g., the need for increased spacing, ventilation
  requirements etc. This work item is expected to be fulfilled with the
  publication of one or more BCPs.
 
- I also agree with the other ADs that it is unclear what this guidance could look like.

Thanks,
Rob

[Ballot block]
Concur with Martin Duke's position.  I don't follow how the IETF has sufficient expertise to produce a BCP associated with the generic scope of "[m]eeting planning for meetings where special measures are required to manage community health due to venue specific restrictions and/or to comply with any local health regulations, ..."  If possible, please be more specific.  For example, what kind of decisions would this BCP be intended to support?  The provided examples of "the need for increased spacing, ventilation requirements" seem like mitigations suggested by or requirements imposed by entities outside of the IETF.

[Ballot comment]
- I appreciate the improvement to the name.

- I agree with Martin’s concern regarding the futility of the IETF writing BCPs regarding public health measures.

- There is no statement of how the “meeting planning for mostly online… meetings” work item is to be fulfilled. Since the others say they’ll result in one or more BCPs, I’m left to wonder about this one.

[Ballot comment]
- I appreciate the improvement to the name.

- I agree with Martin’s concern regarding the futility of the IETF writing BCPs regarding details of public health measures.

- There is no statement of how the “meeting planning for mostly online… meetings” work item is to be fulfilled. Since the others say they’ll result in one or more BCPs, I’m left to wonder about this one.

[Ballot comment]
- I appreciate the improvement to the name.
- I agree with Martin’s concern regarding the futility of the IETF writing BCPs regarding details of public health measures.
- There is no statement of how the “meeting planning for mostly online… meetings” work item is to be fulfilled. Since the others say they’ll result in one or more BCPs, I’m left to wonder about this one.

[Ballot block]
I have trouble seeing what high-level principles a BCP regarding compliance with health policies will enumerate. Isn't it pretty much "do what the health authorities tell us to do"? Is the intent to establish red lines to cancel (but cancellation criteria are out of scope). Or is it to have principles for rationing access to the venue when capacity see drops? Please clarify what the intent is here.

[Ballot comment]
I suspect that a strong consensus to change the meeting cadence will be elusive, but as the charter has that qualifier it's fine to include it.

[Ballot comment]

(1) The "publication of one or more BCPs" fulfills all the items, except the second one.  For consistency, please add something similar to the second item.  Alternatively, include a single statement (not specific to any item) along the lines of "The work of this WG is expected to be fulfilled with the publication of one or more BCPs."

(2) Milestones should be included.

[Ballot comment]
Thank you for the work to draft this charter in very challenging times... with multiple inputs from the community, getting even a rough consensus is not easy on this topic...

I like the change to "Stay Home Meet *Occasionally* Online" ;-)

Unsure whether the word "hybrid" is used rightfully in 'mostly online, or “hybrid,” meetings'. Suggest to keep only "mostly online" (see also the use of "mostly-in-person" later in the text).

About "manage community health"... so no more ice creams and cookies only fruits ? ;-) Suggest to reword with "sanitary conditions". Anyway, I wonder whether the IETF community has the capacity to author a BCP on this topic (would it create some liability ?)

Still missing any milestone...

[Ballot comment]
My previous comments were not addressed, so, repeating them:

My concern is the work item around the fees. Asking the community feedback about fee and producing informational (non binding) documents seems to say "What do you think? Anyway, IESG/LLC will go my their way!' ... does not sound fair to me.

There are no milestones ;)

[Ballot comment]
I share Ben's concern about the eligibility question: it needs to be addressed somehow; so, let's not forget about this issue.

My own concern is the work item around the fees. Asking the community feedback and producing informational documents seems to say "What do you think? Anyway, I will go my own way!' as informational document will not be binding.

There are no milestones ;)

[Ballot comment]
I share Ben's concern about the eligibility question: it needs to be addressed somehow; so, let's not forget about this issue.

My own concern is the work item around the fees. Asking the community feedback and producing informational documents seems to say "What do you think? Anyway, I will go my own way!' as informational will not be binding.

There are no milestones ;)

[Ballot comment]
If we're intentionally leaving the eligibility question out of scope for
SHMOO (per the previous discussion), what is the story for actually
advancing the eligibility work?  I don't remember seeing anything go by
that implied that we should prioritize SHMO and drop the eligibility
work, and would be sad if that is what happens.

"the experience of handling meeting planning during the pandemic has
proven that having community consensus guidance at hand when dealing
with novel conditions in the future would be beneficial" seems to be
setting up almost an open slate for potential "novel conditions" that
the WG will consider.  Is there any sort of additional guidance to give,
or are we just implicitly assuming that the guidelines that would have
been useful for the pandemic situation would be relatively transferrable
to other "novel conditions"?

[Ballot comment]
Roman has some good comments; thanks.

A minor editorial thing in addition: two instances of "SHMO" in the body need to be changed to "SHMOO".

[Ballot comment]
** Recommend consistent language:

-- “The SHMO working group is therefore chartered to provide _high-level guidance_ ...”

-- “The work of SHMO is expected to produce _high-level principles_ ...”

Choose either guidance or principles.

** I’m stumbling a bit on the editorial symmetry by which the core areas of work are described. Specifically:

“... high-level guidance ... concerning ...

[a] Criteria for determining when a previously scheduled in-person meeting should be canceled ...

[b] Meeting planning in the event that a previously scheduled in-person meeting is needs to be canceled ...

[c] Functional requirements for technologies ...

[d] What principles need to be considered when determining meeting fees ...

[e] The cadence of meeting scheduling ...”

Work items [b] and [e] are clear.

What is “high-level guidance ... concerning criteria for determining ...” -- is this going to be criteria or guidance on criteria?  RFC8718 is cited as an example, but by my read, it contains both high-level principles (Section 2) and explicit criteria (Section 3).  Are both in scope for the WG?

What is “high-level guidance ... [on] function requirements ...” – is this going to produce actual requirements or high-level guidance on requirements?  Is "high-level guidance on requirements" equivalent to use-cases?  Editorially would be it be "high-level guidance ... [on] The technologies and work-flows the IETF uses to support fully online meetings." 

What is “high-level guidance ... [on] what principles need to be considered ...” – this seems a bit abstract,"high-level guidance on the principles".

** Per “Functional requirements for the technologies the IETF uses to support fully online meetings”, what is the envisioned interplay of this WG with the tools (“The Tools Team”) and tools-arch (“Tools Architecture and Strategy Team”) teams?

[Ballot comment]
This comment was originally entered for the 00-00 version of SHMO and copied to the SHMOO charter.

Since it's already come up once and resulted in an expedited BCP being produced, I think this should be explicit -- one way the other -- about whether discussions about NomCom eligibility will be in scope for this working group.

[Ballot comment]
This comment was originally entered for the 00-00 version of SHMO and copied to the SHMOO charter.

Non-blocking, but I would prefer to leave the “consider less than 3 meetings” bit for a recharter. There is a lot on this WG’s plate and that item attracts a fundamentally different kind of participant.

s/Technology functionality requirements/Functional requirements

[Ballot comment]
This comment was originally entered for the 00-00 version of SHMO and copied to the SHMOO charter.

[[ nits ]]

* s/cancelled/canceled/, for consistency (or vice versa)