Open Stack

Even though I agree the process this time around was comedy of errors
(or worse), I don't think switching to numeric releases is
particularly wise... for example, more than once someone has reported
an issue with Sahara and stated that they are using <some number>
version of Sahara. Turns out that <some number> is actually the
version of the OSA playbooks being used. Let's not add another number
to get confused about into the mix.

Anyway:
- I think that now with you having pointed out everything that went
wrong and having pointed us towards the simple steps that should be
followed instead, we ought to give ourselves one more try to get the
process correct for "V". We really should be able to get it right next
time and there's something to be said for tradition.
- I did not see in the document about how to determine the geographic
region (its size etc or who should determine it). This is an
opportunity for confusion sometimes leading to bitterness (and it was
in the case of U -- whole China versus near Shanghai).

Just some thoughts.

P.S.: Single letter (like "U", "V") doesn't work when we wrap the
alphabet (as has already been observed), but something like "U21",
"V22", ... "A27" seems to work fine.

On Tue, Aug 13, 2019 at 3:03 PM James E. Blair <corvus at inaugust.com> wrote:
>
> Rico Lin <rico.lin.guanyu at gmail.com> writes:
>
> > (Put my whatever hat on)
> > Here's my suggestion, we can either make a patch to clarify the process
> > step by step (no exception) or simply move everything out of
> > https://governance.openstack.org/tc
> > That actually leads to the current discussion here, to just use versions or
> > not. Personally, I'm interested in improving the document and not that much
> > interested in making only versions. I do like to see if we can use whatever
> > alphabet we like so this version can be *cool*, and the next version can be
> > *awesome*.  Isn't that sounds cool and awesome? :)
>
> I'm happy to help improve it if that's what folks want.  I already think
> it says what you and several other people want it to say.  But I wrote
> it, and so the fact that people keep reading it and coming away with
> different understandings means I did a bad job.  So I'll need help to
> figure out which parts I wasn't clear on.
>
> But I'm serious about the suggestion to scrap names altogether.  Every
> time we have an issue with this, it's because people start making their
> own judgments when the job of the coordinator is basically just to send
> some emails.
>
> The process is 7 very clear steps.  Many of them were definitely not
> followed this time.  We can try to make it more clear, but we have done
> that before, and it still didn't prevent things from going wrong this
> time.
>
> As a community, we just don't care enough to get it right, and getting
> it wrong only produces bad feelings and wastes all our time.  I'm
> looking forward to OpenStack Release 22.
>
> That sounds cool.  That's a big number.  Way bigger than like 1.x.
>
> > And like the idea
> > Chris Dent propose to just use *U* or *V*, etc. to save us from having to
> > have this discussion again(I'm actually the one to propose *U* in the list
> > this time:) )
>
> That would solve a lot of problems, and create one new one in a few
> years. :)
>
> > And if we're going to use any new naming system, I strongly suggest we
> > should remove the *Geographic Region* constraint if we plan to have a poll.
> > It's always easy to find conflict between what local people think about the
> > name and what the entire community thinks about it.
>
> We will have a very long list if we do that.
>
> I'm not sure I agree with you about that problem though.  In practice,
> deciding whether a river is within a state boundary is not that
> contentious.  That's pretty much all that's ever been asked.
>
> > (Put my official hat on)
> > And for the problem of *University* part:
> > back in the proposal period, I find a way to add *University* back to the
> > meet criteria list so hope people get to discuss whether or not it can be
> > in the poll. And (regardless for the ongoing discussion about whether or
> > not TC got any role to govern this process) I did turn to TCs and ask for
> > the advice for the final answer (isn't that is the responsibility for TCs
> > to guide?), so I guess we can say I'm the one to remove it out of the final
> > list. Therefore I'm taking the responsibility to say I'm the one to omit
> > *University*.
>
> Thanks.  I don't fault you personally for this, I think we got into this
> situation because no one wanted to do it and so a confusing set of
> people on the TC ended up performing various tasks ad-hoc.  That you
> stepped up and took action and responsibility is commendable.  You have
> my respect for that.
>
> I do think the conversation about University could have been more clear.
> Specific yes/no answers and reasons would have been nice.  Instead of a
> single decision about whether it was included, I received 3 decisions
> with 4 rationales from several different people.  Either of the
> following would have been perfectly fine outcomes:
>
> Me: Can has University, plz?
> Coordinator: Violates criterion 4
> Me: But Pike
> Coordinator: Questionable, but process says be "generous"
>              so, okay, it's in.
> or
> Coordinator: <Insert reason pike is invalid precedent>.  Sorry, it's
>              still out.
>
> However, reasons around trademark or the suitability of English words
> are not appropriate reasons to exclude a name.  Nor is "the TC didn't
> like it".  There is only one reason to exclude a name, and that is that
> it violates one of the 4 criteria.
>
> Of course it's fine to ask the TC, or anyone else for guidance.
> However, it's clear from the IRC log that many members of the TC did not
> appreciate what was being asked of them.  It would be okay to ask them
> "Do you think this meets the criteria?"  But instead, a long discussion
> about whether the names were *good choices* ensued.  That's not one of
> the steps in the process.  In fact, it's the exact thing that the
> process is supposed to avoid.  No matter what the members of the TC
> thought about whether a name was a good idea, if it met the criteria it
> should be in.
>
> > During the process, we omitted Ujenn, Uanjou, Ui, Uanliing, Ueihae, Ueishan
> > from the meet criteria list because they're not the most popular spelling
> > system in China. And we omitted Urumqi from the meet criteria list because
> > of the potential political issue. Those are before I was an official. And
> > we should consider them all during discuss about *University* here. I guess
> > we should define more about in which stage should the official propose the
> > final list of all names that meet criteria should all automatically be part
> > of the final list.
>
> None of those should have been removed.  They, even more so than
> University, clearly meet the criteria, and were only removed due to
> personal preference.
>
> I want to be clear, there *is* a place for consideration of all of these
> things.  That is step 3:
>
>   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.
>
> That is where we would identify things like "this name uses an unusual
> romanization system" or "this name has political ramifications".  We
> don't remove those names from the list, but we let the community know
> about the issues, so that when people vote, they have all the
> information.
>
> We trust our community to make good (or hilariously bad) decisions.
>
> That's what this all comes down to.  The process as written is supposed
> to collect a lot of names, with a lot of information, and present them
> to our community and let us all decide together.  That's what has been
> lost.
>
> -Jim
>