some questions from SIG Cluster Lifecycle

[Lubomir I. Ivanov]

hello WG Naming,
Lubomir from SIG Cluster Lifecycle here.

we have been following the plans for creation of this working group
and had discussions around some of the changes that would happen in
our subprojects around clearing the language.

we spent time gathering feedback from our subproject maintainer and
leads and created a short list of important questions that we would
like to get answers for. i'm sure these questions would be critical to
other SIGs and maintainers too.

Q1) would you prefer if the code owners lead the technical process of
a language change with respect to deprecation and removal periods, or
would the WG prefer a more strict timeline - e.g. "we need to clear
the language by mid-2021"?

Q2) there were talks that 1.20 (or a release after that) *could be* a
"stabilization" release, which may imply - no new features or breaking
changes. have you envisioned that this could conflate with the work
around clearing the language in the kubernetes/kubernetes repository
and what would take precedence?

Q3) some maintainers had concerns around larger changes becoming an
unfunded mandate. do you think the WG would be able to help with
staffing from volunteer contributors?

Q4) possibly everyone is interested in the list of terms considered
offensive is defined, even if over time it becomes a living document.
can you estimate when would that initial iteration of the list would
be available?

thank you
lubomir
--

[Celeste Horgan]

Hi Lubomir,

Sorry for the delay in response!

Let me speak to the other leads before getting back to you.

Cheers,

Celeste

[Zach Corleissen]

> Lubomir from SIG Cluster Lifecycle here.

:wave: Thanks for your patience, and thanks for your questions.

> we have been following the plans for creation of this working group

> Q1) would you prefer if the code owners lead the technical process of

> a language change with respect to deprecation and removal periods, or

> would the WG prefer a more strict timeline - e.g. "we need to clear

> the language by mid-2021"?

One clarification: WG Naming makes recommendations to the Steering Committee (SC), who ultimately decide what to implement.

That said, I think timeline recommendations can be both communal (aspiring to a target date project-wide) and SIG-driven for specific implementations. Does that seem reasonable to you? 

> Q2) have you envisioned that this could conflate with the work

> around clearing the language in the kubernetes/kubernetes repository

> and what would take precedence?

Can you clarify what you mean by precedence? 

Also, consider that removing harmful language is a stabilizing feature.

> Q3) some maintainers had concerns around larger changes becoming an

> unfunded mandate. 

The alternative is that racist and other harmful language continues to be funded. That's not a recommendation WG Naming can make in good faith to the SC.

> do you think the WG would be able to help with staffing from volunteer contributors?

Two of WG Naming's leads are approvers in SIG Docs, which will bear a significant amount of the work involved in identifying, reviewing, and maintaining content affected by WG Naming's recommendations and the SC's decisions. We are, as they say, all in.

Given that WG Naming consists of four leads and other participants who volunteered for the work, I'm not sure what you're asking.

> Q4) can you estimate when would that initial iteration of the list would

> be available?

We've made one specific recommendation already for allow list/deny list. There's an active discussion in this group about other specific replacements. As you say, that list will likely be a living document.

Of greater interest, I think, is when WG Naming will produce a rubric for evaluating language and proposing change on an ongoing basis. I think the leads all agree that WG Naming ought not to exist in perpetuity, and that our work needs to be both timely for the moment and resilient enough for the SC to adopt in future cases. 

It's too early in the process to offer a tentative date.

Cheers,

Zach

[Lubomir I. Ivanov]

On Wed, 26 Aug 2020 at 23:44, Zach Corleissen
<zcorl...@linuxfoundation.org> wrote:
>
> > Lubomir from SIG Cluster Lifecycle here.
>
> :wave: Thanks for your patience, and thanks for your questions.

no problem, thank you for the responses.

>
> > we have been following the plans for creation of this working group
>
> > Q1) would you prefer if the code owners lead the technical process of
> > a language change with respect to deprecation and removal periods, or
> > would the WG prefer a more strict timeline - e.g. "we need to clear
> > the language by mid-2021"?
>
> One clarification: WG Naming makes recommendations to the Steering Committee (SC), who ultimately decide what to implement.
>
> That said, I think timeline recommendations can be both communal (aspiring to a target date project-wide) and SIG-driven for specific implementations. Does that seem reasonable to you?

i think a lot of developers and users would agree that it is best if
we apply the official k8s deprecation / removal policies for user
facing features:
https://kubernetes.io/docs/reference/using-api/deprecation-policy/

for example, a client side CLI flag that is GA, but contains the word
"master" would have to be in deprecation for "12 months or 2 releases
(whichever is longer)" before it is removed.
aspiring to a project-wide target date is doable and seems ideal, but
we have to consider that this involves synchronization, planning,
prioritization, developer and reviewer bandwidth.

>
> > Q2) have you envisioned that this could conflate with the work
> > around clearing the language in the kubernetes/kubernetes repository
> > and what would take precedence?
>
> Can you clarify what you mean by precedence?
>
> Also, consider that removing harmful language is a stabilizing feature.

admittedly, this question is a bit hypothetical.
to clarify, there were ideas to have a "stability" k8s release where
no new features or breaking changes merge in the release, but if
breaking language change (e.g. removing "master" from a flag) *must*
be done in that release, then obviously either the language change or
the per-release "no breaking changes policy" has to take precedence.

that said, it seems the ideas around a "stability" release might have
been superseded by the "phased release" proposal:
https://groups.google.com/g/kubernetes-dev/c/YXGBa6pxLzo

>
> > Q3) some maintainers had concerns around larger changes becoming an
> > unfunded mandate.
>
> The alternative is that racist and other harmful language continues to be funded. That's not a recommendation WG Naming can make in good faith to the SC.
>
> > do you think the WG would be able to help with staffing from volunteer contributors?
>
> Two of WG Naming's leads are approvers in SIG Docs, which will bear a significant amount of the work involved in identifying, reviewing, and maintaining content affected by WG Naming's recommendations and the SC's decisions. We are, as they say, all in.
>
> Given that WG Naming consists of four leads and other participants who volunteered for the work, I'm not sure what you're asking.

this question in particular came from maintainers of busy sub-projects
that anticipate breaking changes. if the maintainers have a lot on
their plate how do we prioritize their work - we are all assuming that
clearing the language has the highest priority? should the maintainers
drop what they are doing and execute on this work, or do we expect
"help-wanted" labels and the WG Naming project dashboards to attract
volunteers to help with the code changes?

>
> > Q4) can you estimate when would that initial iteration of the list would
> > be available?
>
> We've made one specific recommendation already for allow list/deny list. There's an active discussion in this group about other specific replacements. As you say, that list will likely be a living document.
>
> Of greater interest, I think, is when WG Naming will produce a rubric for evaluating language and proposing change on an ongoing basis. I think the leads all agree that WG Naming ought not to exist in perpetuity, and that our work needs to be both timely for the moment and resilient enough for the SC to adopt in future cases.
>
> It's too early in the process to offer a tentative date.
>

agreed. after seeing the latest discussions on the mailing list, i've
realised that it might be a bit too early to ask such a question.
i can see where i can help with ideas.

thanks!
lubomir
--

[Zach Corleissen]

> i think a lot of developers and users would agree that it is best if 
> we apply the official k8s deprecation / removal policies for user 
> facing features: 
> https://kubernetes.io/docs/reference/using-api/deprecation-policy/ 

Following the deprecation policy for features seems reasonable to me. I'd love to hear input from other WG Naming leads.

> should the maintainers 
> drop what they are doing and execute on this work, or do we expect 
> "help-wanted" labels and the WG Naming project dashboards to attract 
> volunteers to help with the code changes? 

Those are good questions to consider. I'll put them up for discussion at the next WG meeting.

Thanks,

Zach