Open Stack

Suggest we stick to geographically named releases. AT least till we reach Z.
Community and User are well accustomed to it now.
It has marketing value now, so let's keep it.

Thanks,
Arkady

-----Original Message-----
From: Jeremy Freudberg <jeremyfreudberg at gmail.com> 
Sent: Tuesday, August 13, 2019 2:45 PM
To: James E. Blair
Cc: OpenStack Discuss
Subject: Re: [all][tc] U Cycle Naming Poll


[EXTERNAL EMAIL] 

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
>