Formal objection to proposed Kubeflow 1.5 release team

[Mathew Wicks]

Hey All,

I see that @annajung, @jbottum, @kimwnasptd, @shannonbradshaw are taking actions under the banner of a “Kubeflow 1.5 release team”. I don't see how this is possible, as no release team has been endorsed by the Working Groups or Project Steering Group.

I am concerned that having 75% members of the "Kubeflow 1.5 release team" be from one company is not in the best interest of the Kubeflow project. 

• @annajung (VMWare)
• @jbottum (Arrikto)
• @kimwnasptd (Arrikto)
• @shannonbradshaw (Arrikto)

Therefore, as one of the Notebooks WG Leads, I would like to formally object to the proposed release team of @annajung, @jbottum, @kimwnasptd, and @shannonbradshaw.

----

Instead, I propose we follow the same process we used for the "Kubeflow 1.4 release team":

1. Publicly request nominations on "kubeflow-discuss" (see 1.4's thread)
2. Raise a GitHub issue with the proposed release team, and request that the Project Steering Group and Working Groups "endorse" or "object" to the group (see 1.4's issue)

----

I have raised issue #540 on "kubeflow/community" to discuss how we formally agree on the Kubeflow 1.5 release team, and I encourage comments and discussion.

Regards,

Mathew Wicks

[Mathew Wicks]

Hey All,

For the benefit of those only on the email thread, I am copying my proposed next steps so we can get the "Kubeflow 1.5 release team" formed ASAP.

(Copied from this comment)

Next Steps:

1. Formally agree that the current "Kubeflow 1.5 release team" has not been established yet
2. Put out a new request for nominations:
   1. (We can limit the time period to 1 week to limit the wasted time)
   2. (People can self-nominate if they like, or nominate others)
   3. (I think a sensible requirement is that a non-affiliated person seconds the nomination)
3. The group of ALL seconded nominations becomes the "proposed release team":
   1. (The specific roles, like "Release Manager" and "Docs Lead" can be decided by consensus among the team)
4. The "proposed release team" will be presented (as a group) in a GitHub issue for "endorsement" or "objection":
   1. (If more than 60% of the Working Groups "endorse" the release team, it is formalized)
   2. (The Project Steering Group gets a hard veto)

Regards,

Mathew Wicks

[David Aronchick]

I think this is very fair - I would like to hear from other folks. If we don’t hear any objections by midnight  on Monday (Pacific Time), I propose the below goes into effect, with the closing of the release team occurring one week from when this goes into effect.

Any thoughts? 

--
You received this message because you are subscribed to the Google Groups "kubeflow-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubeflow-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/8283375c-0732-4dab-a8e0-c1c5f3ecb39dn%40googlegroups.com.

[Keith Adler]

I agree with Mathew Wicks' proposal. It should be a community decision and having a broader representation of companies is best.

Looking forward to 1.5!

[Mathew Wicks]

Hey All,

I see that @kimwnasptd has created a new nomination thread for the Kubeflow 1.5 release team.

Please raise your nominations and seconds on the thread, before Monday 2021-12-06.

Regards,

Mathew Wicks

[Mathew Wicks]

Hey All,

After a relatively lengthy discussion in today's Kubeflow Community Meeting (2021-11-30), the general consensus was:

1. In the interest of releasing Kubeflow 1.5 in a timely way, we should allow the current "Release Team" to manage the release:
   1. (This is in recognition that more diverse representation has already been added to the proposed "Kubeflow 1.5 Release Team")
   2. (However, we still encourage any other members to join, and further increase diversity).
2. In parallel, we should formalize a "Release Working Group":
   1. (This WG would be established using the same process as all the other Working Groups)
   2. (This WG would have a formal charter - like all other WGs - and be stored in the kubeflow/community repo)

I am happy to work with the current "Release Team", and facilitate the creation of a formal charter for this future "Release Working Group". 

Regards,

Mathew Wicks