update landing readme

[mattmoor]

No description provided.

[mattmoor]

We should talk about the audience for this, and the expected process for changes

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[mattmoor]

/lifecycle frozen
/kind good-first-issue

[imjasonh]

Strong +1

I'd argue that unless prospective users can fork and modify this sample, it either shouldn't exist, or shouldn't be marked as a template for easy forking.

I've based a couple PoCs on this sample controller, and I'm always annoyed at all the steps it takes to make it fit my needs. Here's an incomplete list of changes I make every time I fork the template:

• rename pkg/apis/samples/v1alpha1 to pkg/apis/something/v1alpha1 and update references in hack/update-codegen.sh
• rm pkg/client to remove the old generated clients I no longer need
• rename the AddressableService type to MyType, remove its spec and status fields
• move and rewrite pkg/reconciler/addressableservice to talk about my type in my package
• delete anything related to SimpleDeployment, I usually start off only needing one type at first
• change cmd/controller and cmd/webhook to use
• change import paths from knative.dev/sample-controller/... to github.com/my-user/my-repo/... (and inevitably forget some)
• hack/update-codegen.sh until things work, or just give up

Having those steps written down in some official place would help a lot. Including a script that did them for me would be ideal. At that point that's basically 20% of kubebuilder.

[imjasonh]

• update code-of-conduct.md to report code of conduct violations to somewhere other than knative-code-of-conduct@googlegroups.com