Open Stack

On Mon, Aug 12, 2019 at 3:12 PM James E. Blair <corvus at inaugust.com> wrote:

> Jeremy Stanley <fungi at yuggoth.org> writes:
>
> > On 2019-08-11 10:30:32 -0700 (-0700), James E. Blair wrote:
> > [...]
> >> I still do believe that it meets all of the criteria.  In particular, it
> >> meets this:
> >>
> >> * The name must refer to the physical or human geography of the region
> >>   encompassing the location of the OpenStack summit for the
> >>   corresponding release.
> >>
> >> It is short for "University of Shanghai for Science and Technology",
> >> which is a place in Shanghai.  Here is their website:
> >> http://en.usst.edu.cn/
> > [...]
> >
> > This got discussed after last week's TC meeting during Thursday
> > office hours, and I'm sorry I didn't think to give you a heads-up
> > when the topic arose:
> >
> >
> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019-08-08.log.html#t2019-08-08T14:59:01
> >
> > One of the objections raised was that "University" in the name
> > "University of Shanghai for Science and Technology" was a general
> > class of place or feature and not a particular place or feature. But
> > as you pointed out in IRC a while back (and which I should have
> > remembered), there is precedent with the Pike cycle name:
> >
> >     Pike (the Massachusetts Turnpike, also the Mass Pike...)
> >
> >
> https://wiki.openstack.org/wiki/Release_Naming/P_Proposals#Proposed_Names
> >
> > Another objection raised is that "OpenStack University" was the old
> > name for what we now call the OpenStack Upstream Institute and that
> > it could lead to name confusion if chosen. A search of the Web for
> > that name last week turned up only two occurrences for me on the
> > first page of results, both of which were lingering references in
> > our wiki which I immediately corrected, so I don't think that
> > argument holds.
> >
> > Then there was the suggestion that "University" might somehow be a
> > trademark risk, though in my opinion that's why we have the OSF vet
> > the preliminary winning results after the community ranks them (so
> > that the TC doesn't need to concern itself with trademark issues).
> >
> > It was also pointed out that each time we have a poll with a mix of
> > English and non-English names/words, an English name inevitably
> > wins. Since this concern isn't backed up by the documented
> > process[*] we're ostensibly following, I'm not really sure how to
> > address it.
> >
> > Ultimately I was unable to convince my colleagues on the TC that
> > "University" was a qualifying name, and so it was handled as a
> > possible exception to the normal rules which, following a poll of
> > most TC members, was decided would not be granted.
> >
> > [*] https://governance.openstack.org/tc/reference/release-naming.html
>
> Thanks for the clarification.  The only point raised which should have
> any bearing on the process at this time is is the first one, and I think
> that has been addressed.
>
> The process is designed to collect the widest range of names, and let
> the *community* decide.  It is not the function of the TC to vet the
> names for suitability before the poll.  The community itself is to do
> that, in the poll.  And because vetting for trademark is a specialized
> and costly task, that happens *after* the poll, so that we don't waste
> time and money on it.
>
> It was exactly the kind of seemingly arbitrary process of producing the
> names for the poll which is on display here that prompted us to write
> down this more open process in the first place.  It's unfortunate that
> the last three objections that you cite are clearly in contradiction to
> that.
>
> We pride ourselves on fairness and openness, but we seem to have lost
> the enthusiasm for that here.  I would rather we not do this at all than
> to do it poorly, so I have proposed we simply stop naming releases.
> It's more trouble than it's worth.
>
> Here's my proposed TC resolution for that:
>
>   https://review.opendev.org/675788
>
> -Jim
>
> I'm with Jim on this, specially would like to highlight couple of points
from the governance:

"""
#. The marketing community may identify any names of particular
   concern from a marketing standpoint and discuss such issues
   publicly on the Marketing mailing list.  The marketing community
   may produce a list of problematic items (with citations to the
   mailing list discussion of the rationale) to the election official.
   This information will be communicated during the election, but the
   names will not be removed from the poll.

#. After the close of nominations, the election official will finalize
   the list of proposed names and publicize it.  In general, the
   official should strive to make objective determinations as to
   whether a name meets the `Release Name Criteria`_, but if
   subjective evaluation is required, should be generous in
   interpreting the rules.  It is not necessary to reduce the list of
   proposed names to a small number.

#. Once the list is finalized and publicized, a one-week period shall
   elapse before the start of the election so that any names removed
   from consideration because they did not meet the `Release Name
   Criteria`_ may be discussed.  Names erroneously removed may be
   re-added during this period, and the Technical Committee may vote
   to add exceptional names (which do not meet the standard criteria).
"""

The marketing community concerns will be communicated, "but the names will
not be removed from the poll."
Officials should be objective if the name meets the criteria "but if
subjective evaluation is required, should be generous in interpreting the
rules.  It is not necessary to reduce the list of proposed names to a small
number."
"Technical Committee may vote to add exceptional names", not to remove
qualifying names for personal preference.

i think if we take the route taken here, we better just stop naming things.

- Erno "jokke" Kuvaja
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190812/f3c20733/attachment-0001.html>