Code Monkey home page Code Monkey logo

mtgvenue's People

Contributors

elear avatar

Stargazers

 avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

mtgvenue's Issues

Need a real decision tree

From AJS

The first issue is the splitting of the criteria into so many
categories. I don't understand the utility. In terms of actually
making decisions, there are basically three divisions. Criteria that
are mandatory cannot be traded no matter what, and therefore they
ought to be listed together. Criteria that need to be traded off
need, well, to be traded off; so they ought to be listed together too.
All other criteria literally don't matter except as tie-breakers, so
the only reason to list them is to emphasise that certain things are
nicer to have than other ones. The decision tree is a simple tree,
not a multidimensional one, so the additional dimension obscures
matters while adding nothing at all to decision-making.

A solution to this might be either to add another section that lists
the entire decision-rules in one place, or else to recast the category
listing as a single decision-rule table and then provide a
category-based breakout as an appendix or another section.

For instance, here are the criteria listed in decision-rule form (I
think I got it all):

Mandatory: No Venue failure from community consultation, Venue
acceptable travel, Venue host and sponsors, Venue low barriers to
entry, Venue travel issue assessments, Facility size and layout,
Facility costs, Venue cash positive, Facility easy for wheelchairs,
Facility-techno support ok, Facility-techno network ok, Hotels-techno
network ok, Hotels proximity ok, Hotels number ok, Hotels contracts &
costs ok, Venue cheap hotels poss, Hotels wheelchairs ok, Venue
environs meal choices ok, Venue food restrictions ok.

Important: Venue disabilities ok, Hotels disabilities ok, HQ Hotel
lounge, Venue environs groceries.

Desired: Venue Multi-event contract, Facility one roof, Hotels
Internet ok.

Process innovation

From AJS:

I don't know whether I've just not made this clear, or whether the
editors really disagree with me, but §4.1 appears to me to suggest
that we have a standard IETF consensus call about many issues related
to venues, and combined with the "is acceptable" language in §3 looks
to me like an enormous potential burden with possibly appealable
consequences. I think this is a terrible idea.

It's this ¶ in particular that makes me worried:

IETF consensus, with respect to this meeting Venue selection process
is judged via standard IETF process and not by any other means, e.g.,
surveys. Surveys are used to gather information related to meeting
venues, but not to measure consensus or to be reported as
consensus.

If the below is what's meant instead, I can live with it (though I
think it could in that case be removed as it is already determined
elsewhere):

IETF consensus, with respect to the meeting venue selection process
herein outlined, is judged according to standard IETF process and
not by any other means, e.g., surveys. Surveys are used to gather
information related to Venues, but not to measure consensus
or to be reported as consensus. By the same token, Venue decisions
are not themselves subject to IETF consensus, and are instead
decisions taken by the IAOC.

More than 1 hq hotel?

From Jordi:

The IETF Headquarters Hotel has a space for use as a lounge …” This text need to be rewritten, as it is assuming that there is only one “headquarter” hotel. What if we have 4 as main hotels, because among them fulfill our needs?

Text seems strange

From Jari:

2.2. Venue Selection Non-Objectives

Maximal attendance:
Because the IETF garners a significant portion of its revenue from
IETF meeting fees, there is considerable incentive for decision-
makers to prefer a Venue that will attract more attendees. It is
important to resist this temptation: a larger meeting in which key
contributors could not make it is not a better meeting; neither is
one with a lot of "tourists”.

This is correct, but sounds a bit strange. Maybe not the whole
truth.

I’d add “Yet, meetings need to be open and accessible for
both key contributors and others, including new contributors."

Sponsor required as mandatory?

From Jari:

+------------------------------------------------------+------------+
| The Venue is assessed as favorable for obtaining a | "Mandatory |
| host and sponsors. That is, the Meeting is in a | " |
| location and at a price that it is possible and | |
| probable to find a host and sponsors. | |
+------------------------------------------------------+——————+

My personal opinion is that with increasing number of
large global corporations working on Internet tech, and
the IETF global host program, the reliance on finding
local hosts is reduced a bit. We still have to fight to find
sponsors and hosts, and if the meeting location is
somehow undesirable for sponsorship, that would be
an issue. But the text above could be interpreted
in different ways. I’m worried that we may not all
understand it the same. Does it assume a local
host model?

My suggestion would be to change text or downgrade
from mandatory.

Concurrent objection?

In §5.2, should we provide a period for a concurrent objection to the
posted list? That is, it'd be nice if there were a way for people to
say, "I know you're already investigating this place. I still have
concerns, so please look into…" I am of two minds about this, so
that's why this is a question and not a claim that we should.

Too much mandatory

From AJS:

[There are] an enormous number of "Mandatory" and not very many
things that can be traded off, let alone things that are just nice to
have. (It's also interesting that one of the "nice to haves" has been
the reason given to me not even to look at a number of places in the
explanations, so I'm not convinced that reflects actual practice.
That's a separate problem.) But if you look carefully at the Mandatory
cases, I think they're not all really Mandatory. For instance (I'm
picking just one at random, so that this is the example isn't
significant):

Travel to the Venue is acceptable based on cost,
time, and burden for participants traveling from
multiple regions. It is anticipated that the burden
borne will be generally shared over the course of
multiple years.

The problem is, if I am evaluating that, I don't know what "is
acceptable" means. It's either empty (because, by definition, if
people show up the cost was acceptable) or else it's waving away the
contentiousness around "acceptable". More importantly, since this
explicitly says that it's to be shared over the course of years, it's
actually an Important, and not Mandatory, item.

This is part of the reason I noted the other day that I just couldn't
tell whether the distinction Alissa and I had previously tried to make
is captured in the draft. I believe that the various inconveniences
of informal travel restrictions that make visa-granting a crapshoot
are to be traded off, because we need to be prepared for the
possibility that people of one country or another are going to get
jerked around in any Venue. At the same time, I believe that formal
bans against some class of people where that ban is not empirically
founded ought to be complete disqualifiers. Legal restrictions on
(say) Upper Slobbovians or L-chromosome carriers are not ok and we
should eschew such sites. Informal restrictions that turn out this
year to be capriciously applied against Lower Sobbovians and
M-chromosome carriers are not ok and are to be deplored, but are
predictable consequences of going from country to country.

I therefore think that a very serious look at what is Mandatory vs
Somethingelse is needed, with a view to reducing the Mandatory list.
Anything that has tradeoffs in it is automatically not Mandatory.
Anything else that seems to have room for wiggle is similarly not
really "Mandatory" except in the sense that there is some floor below
which the IAOC's judgement should say, "This is too onerous."

At bottom, that latter issue may be my real concern, because the
"Mandatory" list seems to offer a false objectivity. The items are
all Mandatory, but since many of them involve descriptions that invoke
an enormous amount of judgement they're not really mandatory in the
English sense of the word at all. They're important, and they're also
Important in the sense this draft describes. They can be balanced
against one another, in a way that (for instance) a Venue actually having
enough meeting rooms and having them close enough to each other to
permit a meeting just cannot. We can't have a meeting without this
one:

The Facility is adequate in size and layout to
accommodate the meeting and foster participant
interaction.

We maybe could have a meeting without this one, but it might be
smaller:

The cost of guest rooms, meeting space, meeting
food and beverage is affordable, within the norms
of business travel.

And we totally could have a meeting without this one, because we've in
fact done it (unless "allow" here is construed to mean "logically
possible):

The economics of the Venue allow the meeting to be
net cash positive.

Note that I'm particularly worried about all these Mandatories because
of §5.4 a.

MUST if enough time

In section 5 of -06, we have this:

When there is enough time to do so, the IAOC
MUST consult the community about changes.

That reads like "MUST except when you don't have to", which isn't really MUST at all. I suggest this alternative: "When there is enough time to do so, the IAOC is expected to consult the community about such changes."

What means "mandatory/important/..."

Draft makes clear that if something mandatory is not met, we walk away. But RFC 4071 doesn't really provide for any force in that sort of mandate.

unfiltered should be mandatory

From Alissa (trimmed for readibility):

Commenting as an individual below ...

The IETF Hotel(s) directly provide, or else permit…

The full text of this one is:

The Facility directly provides, or permits and facilitates, the delivery of a high performance, robust, unfiltered and unmodified IETF Network.

Personally I think this should be a mandatory criterion, i.e. we should not select a venue that cannot provide this. If this needs to reference the meeting network requirements document to provide the objective criteria by which it will be judged, that would be fine, I think.

Whether the IAOC has executed a process step is not a criterion

One of the mandatory requirements in the document is listed as:

"Available travel issue assessments ... have been pointed out the IETF community."

This is not a criterion for meeting venue selection. Either this is a process step that the IAOC is expected to take and it should be included in the description of the process and taken for every venue, or it isn't. There shouldn't be criteria that depend solely on whether the IAOC executed its expected process.

Align mandatories with values

From Laura Nugent:
have been following the discussion with great interest and, from where I sit, it seems we have lost sight of the bigger picture and are focusing on details instead. Following is my attempt to look from a fresh perspective at the purpose of this document.

My questions for this group are:
A. Do the criteria identified in the document adequately represent the IETF core values as they apply to venue selection?
B. Does the document provide useful guidance in selecting venues (i.e. can it be implemented and if it can, are the results appropriate)?

  1. Core Values - I believe we need to ensure this document actually reflects IETF core values. To accomplish this, I suggest we consolidate the items listed into three (or two) values, as some of the items listed don’t actually appear to be IETF core values in themselves. I suggest:
    a. Advancing the IETF Mission - this would include all the basic meeting requirements that allow IETF to function and continue to function and do the standards development work
    "We meet to pursue the IETF mission, in part, through the advancement and development of Internet Drafts and RFCs. We also seek to strengthen the IETF community, facilitate attendee participation in IETF projects and activities and enable cross-polination of ideas and technologies.”

    b. Internet Access - this would include everything related to the IETF meeting network. This could easily be part of “Advancing the IETF Mission”, or could be listed separately for emphasis:
    "We write specifications for the Internet and use it heavily. We require, at the Facility, Headquarters Hotel and overflow hotels, unfiltered access to the Internet and attendee corporate networks, which are typically accessed through encrypted VPNs. We also need open network access available at high enough data rates to support our work, including the support of remote participants.”

    c. Inclusiveness - this would include the current items listed under inclusiveness as well as “Economics” and “Least Astonishment”:
    "We seek to facilitate onsite and remote participation of anyone interested in being involved with the IETF.

    1. Entry restrictions - Every country has limits on who it will permit within its borders. However, the ETtF seeks to minimize situations in which onerous entry regulations prevent participants from attending meetings, or failing that, to distribute the meeting locations such that onerous entry regulations are not always experienced by the same attendees
    2. Discrimination - The IETF seeks to avoid meeting in countries with laws that effectively exclude people on the basis of race, religion, gender, sexual orientation, national origin or gender identity
    3. Burden sharing - We meet in a variety of global locations in order to spread the difficulty and cost of travel among active participants, balancing travel time and expense across the regions in which IETF participants are based. Meeting attendees participate as individuals. While many are underwritten by employers or sponsors, many are self-funded. In order to reduce participation costs and travel effort, we seek locations that provide convenient budget alternatives for food and lodging. Within reason, budget should not be a barrier to entry.
    4. Understanding risks - The community needs the opportunity to engage early to express views on prospective selectioins so that community members, the IAOC, and the IAD can discuss prospective venue, concerns or issues long before a venue contract is considered."

I have created a spreadsheet (attached), organizing the criteria based on the core values (core values as consolidated, above and criteria as modified in my further comments, below). Hopefully looking at the criteria from this perspective will help us to understand whether the criteria adequately reflect our core values.

  1. Criteria - There are a number of items included as criteria that I would eliminate or modify for a variety of reasons, explained below:
    a. "Available travel issue assessments…" I believe this should be eliminated as it is not a criteria but part of a process.

    b. "The facility permits easy wheelchair access”
    c. “The Facility is accessible by people with disabilities”
    d. “The IETF Hotel(s) permit easy wheelchair access”
    e. “The IETF Hotel(s) are accessible by people with disabilities”
    There are laws which govern accommodations for disabilities, which laws vary from location to location. We are legally bound to comply with local disability laws. Singling out these four items is misleading, in my mind, as it appears to limit our obligation and to exclude some disabilities. I suggest, in place of these four items, we instead borrow the introductory text as the criteria to govern this concern:
    “Facilities selected for IETF meetings conform with local health, safety and accessibility laws and regulations.”

    f. “The Facility environs include grocery shopping that will accommodate a wide variety…” I suggest that this be combined with the other criteria related to dietary requirements for simplicity and to avoid redundancy:
    “A range of dietary requirements can be satisfied through onsite service or through access to an adequate grocery within a reasonable walking distance or conveniently accessible by a short taxi, bus or subway ride."

    g. “The economics of the venue allow…” I suggest, for clarity, that this criteria be reworded as follows:
    “Anticipated meeting revenues are greater than anticipated meeting expenses ”

    h. “The Facility’s support technologies and services…” I suggest that this be simplified to a more general statement so as to encompass, for example, F&B services. Further, the reference to costs should be eliminated as it is covered by item g, above.
    “The Facility’s support technologies and services are sufficient for the anticipated activities of the meeting, or the Facility is willing to add infrastructure to support technologies and services, or these technologies and services may be provided by a third party."

    i. “The IETF Hotell(s) directly provide, or else permit and facilitate…”
    j. “The overflow hotels provide reasonable, reliable, unfiltered…”
    Reference to the inclusion of Internet in the guest room rate should be eliminated. Assessment of costs is addressed in another criteria (“The cost of guest rooms, meeting space…”).

    k. “The IETF Headquarters Hotel has a space for use as a lounge…” I suggest the description of this criteria be made more concise and implmenetable, as follows:
    “The IETF Headquarters Hotel has a space for use as a lounge to facilitate casual IETF attendee interactions. This lounge can be the hotel bar or casual restaurant.”

    l. “Travel to the region is acceptable based on cost, time and burden…” I suggest, for clarify, that this criteria be reworded as follows:
    “Travel to the venue is acceptable based on cost, time and burden for participants traveling from multiple regions, balanced among regions over multiple years.”

    m. “Overflow Hotels can be placed under contract…” I suggest this be re-written to eliminate the reference to rates, as rates are covered in other criteria:
    “Overflow Hotels can be contracted and are within convenient travel time of the Facility."

  2. Level of requirement - As you will see when you look at the attached spreadsheet, the current document identifies almost all the criteria as mandatory. I believe we need to re-examine the classifications. If a criteria has any room to “bend”, either for the current meeting or in combination with future meetings, I believe it must be listed as “desired”. I understand that this creates some challenges because some criteria may be only “desired” as they relate to one meeting but are “mandatory” as they relate to a year or more of meetings. Balancing these criteria, as has been stated over and over again, remains the challenge of the IAOC.

  3. Process - is it appropriate and necessary to include the process in the criteria document?

Thank you for your time. I look forward to your comments.

ID-VenueSelection-AsChart-10Feb2017.xlsx

What is consensus on? venue selection or process?

From Jari:

IETF consensus, with respect to this meeting Venue selection process
is judged via standard IETF process and not by any other means, e.g.,
surveys. Surveys are used to gather information related to meeting
venues, but not to measure consensus or to be reported as consensus.

As noted in another mail, this is unclear. The consensus is on the process,
not on individual venue selection decisions. (And perhaps you could
also explain that if there’s widespread concern of a venue, then
that should show up in the public consultation, and hence the location
should not make it to selection.)

Local support

From Jordi:

I think it will be VERY important to have a local, which is also involved in the IETF, and knows the venue and the neighborhood of the facilities being evaluated, to help the on-site survey team. This could be added to 5.3 Qualification

Terminology hard to follow

From: AJS

There are some tricky bits of the definitions because
they seem gappy. We have a requirement of the Venue under the
Facility division, a notion of "Venue environs" that is a little
tricky given the meaning of Venue (maybe that's Facility environs?
Something else?), and a "Venue contract" which is probably a Facility
or Hotel or something contract. I don't have a lot more to say here
because I still want to be sure we're in agreement about the large
before I tackle the middlin'. But the terminology is hard to follow,
which might be partly because of the two-dimensional categories. I
think another problem might be that we need to define separately
Location, maybe City?, and maybe something else -- Greater
Neighbourhood is all I can come up with -- to make this work
reasonably. (This becomes obvious in 5.1 where the tension between
Venue and city is most stark.)

Handling repeats

From Jari:

+------------------------------------------------------+------------+
| It is possible to enter into a multi-event contract | "Desired" |
| with the Venue to optimize meeting and attendee | |
| benefits, i.e., reduce administrative costs and | |
| reduce direct attendee costs, will be considered a | |
| positive factor. Such a contract can be considered | |
| after at least one IETF meeting has been held at the | |
| Venue. | |
+------------------------------------------------------+------------+

Yes, support that.

But, I wonder if we’re hiding important things in the
details; cart before horse. In an so far unpublished
note that I’m writing on IASA 2.0, I had written
the following suggestion:

Repetitive Meeting Schedule

  The IETF meeting cycle should move to a model where 5 meetings
  within a year are repeats in previously qualified hotels and
  locations, and at most 1 meeting is a new one.  The process for
  the previously qualified and new meetings shall be separated.  For
  instance, a contractor can be asked to arrange the repeat meetings
  with only approval for the final hotel agreement taken to the
  IAOC, and then more community and IAOC energy can be used to vet
  the new locations.

I’m not necessarily suggesting this exact model be adopted.
But if the document said “do repeats, and when you are
not repeating, THEN this complex set of requirements need
to be investigated”, maybe that would improve our process?

Note that the IAOC has pretty much gotten the point that the
community wants repeats. Looking from inside, the process
though is largely still the same for everything, which to me
seems wasting effort.

Of [those], it is not necessarily easy to “just repeat”, hotel availability
is a big issue for instance. I’ve been wanting to go back to Japan
for instance so many times already, but there are
challenges

No guns

From Jordi:

I think we must not hold meetings in venues that allow people to carry firearms. I know this may be a conflict for many people that believe that self-defense is a right, but I agree that is true in the street, but inside a venue? If a venue is not considered safe so it “encourages people to carry a gun”, then there is no discussion on that, we should not meet in that venue.

freedom of expression

From Jordi:

Section 2.1 point 2, should include “freedom of expression for the participants”.

Timing of 3 month final check?

From Jari:

5.5. Final Check

~3 Months prior to the Meeting, the site is checked for continued
availability and conformance to expectations.

This might have to be split; three months is a good time to do
a review, but clearly issues could occur at any moment. And we
get reports from our contractor of safety or other issues appearing
in the region.

Clarity on definitions re hotel rooms and the facility in Section 3

From AJS:

I'm not sure what to make of the definition in §3 where hotel rooms
might or might not be part of Facility. This seems strange, though I
guess it's probably because of the IETF network? If so, say that.
(But given that IETF Hotels and HQ Hotel are defined, this seems
wrong.)

Odd that accessibility requirements differ

From Jari:

+-----------------------------------------------------+-------------+
| The Facility permits easy wheelchair access. | "Mandatory" |
+-----------------------------------------------------+-------------+
| The Facility is accessible by people with | "Important" |
| disabilities. | |
+-----------------------------------------------------+-------------+

  1. Odd that the requirement levels differ

  2. As an IAOC member I don’t have a clear understanding of what
    to look for when assessing the second item.

Distinction between these two requirements?

+-----------------------------------------------------+-------------+
| The Facility directly provides, or permits and | "Mandatory" |
| facilitates, the delivery of a high performance, | |
| robust, unfiltered and unmodified IETF Network. | |
+-----------------------------------------------------+-------------+
| The IETF Hotel(s) directly provide, or else permit | "Mandatory" |
| and facilitate, the delivery of a high performance, | |
| robust, unfiltered and unmodified Internet service | |
| for the public areas and guest rooms; this service | |
| is typically included in the cost of the room. | |
+-----------------------------------------------------+——————+

I didn’t understand the distinction between these two items.

s/IAOC/IASA?

Brian Carpenter:

I just noticed a fundamental issue that affects both draft-ietf-mtgvenue-iaoc-venue-selection-process and draft-ietf-mtgvenue-meeting-policy.

They both keep referring to the IAOC as if it were an executive body. It isn't; it's an oversight committee. The executive body is the IASA, led by the IAD.

To a large extent this can fixed by a global s/IAOC/IASA/ in both documents. There may be some places where a little rephrasing is needed.

If you want to discuss the principle of what I'm saying, that belongs on the [email protected] list. But under RFC4071, there really is no doubt that the executive body for meeting planning is IASA. The IAOC's role is overseeing the results.

Clarity of responsibility

From AJS:

I think that §§4.4 and 4.7 could be a whole lot clearer that the
responsibility for Venue selection rests ultimately with the IAOC and
that it's those people about whom IETF participants should complain to
the nomcom, if and when needed.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.