[Update Project]: Clarify Headlamp's status across CNCF/Kubernetes

[joaquimrocha]

Name

Clarify Headlamp's status (and for any similar future projects) across CNCF/Kubernetes

Short description

Headlamp was a sandbox project which joined the Kubernetes project under the SIG UI, but it's still listed in many places as a sandbox project.

Responsible group

TOC

Does the initiative belong to a subproject?

Yes

Subproject name

Headlamp

Primary contact

@joaquimrocha

Additional contacts

No response

Initiative description

Hey everyone! Back in April, Headlamp joined the Kubernetes SIG UI. Since then we have been adapting the project to align with the practices in Kubernetes and some things remain, like what sort of CNCF project it is.
As far as I understand, the Headlamp project is now graduated since joining the Kubernetes project. However, I am trying to clarify its status and update it where it still says sandbox.

From asking some questions around this topic, I believe it's good to bring this subject up, given the uncommon trajectory of Headlamp, should we come up with a clear direction/answers for it and future projects alikes.

Deliverable(s) or exit criteria

Here are things to clarify (in the case of Headlamp, but again, likely for any project that does a similar trajectory):

• What to have in the website footer?
  Till now, we had the "Headlamp is a CNCF Sandbox project". Given that now we're under Kubernetes SIG UI, should we change it to something like this PR (We are a Cloud Native Computing Foundation project, as part of the Kubernetes SIG UI), or we go simply with s/sandbox/graduated/?
  I know being part of Kubernetes means we're also part of the CNCF, but I believe the CNCF footer works like a legitimacy badge for projects, helping users and companies' perception, especially those less familiar with Kubernetes and the way the SIGs work. Maybe we could have a special footer for projects that are part of Kubernetes.

• What should the CNCF Landscape display?
  I have opened a PR to update Headlamp's info in the CNCF Landscape. I have noticed however, that projects under Kubernetes in some (most?) cases do not have anything about whether they are graduated, nor that they are part of Kubernetes.

• How should we update the foundation membership/maintenance info?
  I opened this PR, but not sure if this is the correct way.

• How should we apply for a kiosk at KubeCon?
  Should we still apply as an individual project? Or should we apply as SIG UI?

• Can we keep the CNCF Project Dashboard? And the website + legacy Github org?
  The project dashboard is very helpful for organizing the community calls, etc.
  About the website, it's almost like the footer/badge question. It's a good way to have a dedicated frontpage about the project.
  The legacy github org is less important, but we keep a few projects there while we are still adapting to Kubernetes' way of maintenance.

• How should we sign the Headlamp desktop apps?
  Previously we were signing Headlamp using Microsoft's certificates. However, given the project move under the Kubernetes SIG UI, we should find a different solution for signing it. I have filed a service desk issue exposing this to the CNCF over a year ago and there were some progress around London's KubeCon according to @krook , but the subject seems to be stalled again. So currently Headlamp's desktop apps are not being signed and this is having a negative impact in the project, especially in its adoption for professional use-cases. IMO it would be very beneficial to have a way for users to trust apps build under the CNCF projects beyond the GPG signs.

Any guidance on these topics is very much appreciated. Thank you!

[joaquimrocha]

Updated to include the codesign of desktop apps.

[leonardpahlke]

The points listed seem to be all important, but I am not sure if an initiative is the best format to explore this. Questions around KubeCon kiosk seem to be organizational questions between the TOC and K8s? In general, this hints towards the question of how to capture projects in the landscape (and by the TOC & TAGs) that are part of another project, like a lot of the K8s projects or Cilium, etc.. Perhaps something to consider exploring on the TOC agenda cc @angellk

[joaquimrocha]

@leonardpahlke Yeah. I was not sure which category of issue would fit this one the best, so I chose initiative in the sense that clarifying all these can be a good thing to lay for the future, but happy to have this changed to whatever. I do feel it's good to have an umbrella issue for it (i.e. one place).

[angellk]

thank you @leonardpahlke and @joaquimrocha ! This looks like more of an issue for the projects team (versus an Initiative)
cc: @krook