Create Developer Persona for Knative

[omerbensaadon]

What is changing? (Please include as many details as possible.)

We want to create a developer persona, complete with persona name, attributes, wants, needs and pains.

Context

The DUX WG has expressed interest in separating the documentation by persona, this would be a first step in achieving that outcome.

How will this impact Knative users?

Users will more easily be able to find topics relevant to their persona as a developer, and not be bogged down with the complexity of other persona's needs (such as administrators)

Prototype

N / A

Potential Feature List

N / A

[joshuawilson]

Developer:

• does not have admin rights
• may not even know how to install knative
• should be able to install 'kn'
• is focused on building an app
• would want to deploy it as a service
• will write eventing features into their app
• will not use the API
• will use the CLI or IDE extension.
• will want to configure Eventing with their app
  • Create, Read, Update, Delete all or any of the 5 components of Eventing in the process connecting them to their app
  • What are the highest priority components? I think Source is an important starting point.
• need to be able to test/experiment with Eventing and their app
• verify that events are flowing to their app

As a developer, I want to take my existing application running on my local machine and deploy it as a knative Service so I can confirm that it works, this is not for production deployment. (This could be deployed to minikube or a developer namespace on a running cluster)

As a developer, I want to take my existing application with non-knative eventing but using some form of events and configure it to use Eventing so that I can take advantage to Knative.

[evankanderson]

Ref:

• https://github.com/knative/serving/blob/main/docs/product/personas.md#developer-personas
• https://github.com/knative/eventing/blob/main/docs/personas.md#event-consumer-developer

Developer Personas

The developer personas are software engineers looking to build and run a stateless application without concern about the underlying infrastructure. Developers expect to have tools which integrate with their native language tooling or business processes.

• Hobbyist
• Backend SWE
• Full stack SWE
• SRE

User stories:

• Deploy some code
• Update environment
• Roll back the last change
• Debug an error in code
• Monitor my application

Event consumer (developer)

An event consumer may be a software developer, or may be an integrator which is
reusing existing packaged functions to build a workflow without writing code.

User stories:

• Determine what event sources are available
• Trigger my service when certain events happen (event feed)
• Filter events from a provider

Event producer

An event producer owns a data source or system which produces events which can
be acted on by event consumers.

User stories:

• Publish events
• Control who can create Feeds

[evankanderson]

My big comment though (copied from Slack):

The developer persona probably has some idea of what they want to build, and wants to figure out which parts they can use Knative for. That probably starts with something like a “toy app” that shows what you can do with serving & eventing (probably in that order).

For their target application, the developer will want to be able to do things like connect to their preferred data storage and integrate with external systems, but they are probably okay starting with a simple app that shows what Knative can and can't do, and where they need to reach for other parts of the toolbox.

Scott had a nice demo at the Atlanta meetup that had a color selection app and then used events to record what color was selected and make a picture from the received events.