Remove political opinions from documentation

[ph-hector]

Everyone can believe whatever they want, as long as it does not infringe on the freedom of others.
I am hereby submitting a request to remove all political opinions from the technical documentation. We are among professionals, not at a political or social-justice convention.
I am thinking in particular of this block:

Personas
Ian (he/him) is an infrastructure provider. His role is the care and feeding of a set of infrastructure that allows multiple isolated clusters to serve multiple tenants. He is not beholden to any single tenant; rather, he worries about all of them collectively.

Chihiro (they/them) is a cluster operator. Their role is to manage a single cluster, ensuring that it meets the needs of its several users. Again, Chihiro is beholden to no single user of their cluster; they need to make sure that the cluster serves all of them as needed.

Ana (she/her) is an application developer. Ana is in a unique position among the Gateway API roles: her focus is on the business needs her application is meant to serve, not Kubernetes or Gateway API. In fact, Ana is likely to view Gateway API and Kubernetes as pure friction getting in her way to get things done.

This adds no technical value, may introduce unnecessary confusion, and could be perceived as inappropriate or distracting by some readers.

Thank you for your understanding.

[kflynn]

I’m not sure if you’re talking about the roles, the personas, or persona-based design in general here, but let me try to clarify why the personas are there and how we’ve found them useful.

The choice to explicitly think about roles when designing Gateway API goes back to the beginning of the project: Ana’s needs, Chihiro’s needs, and Ian’s needs are all distinct, and thinking carefully about how each of them will be affected by the API design has proven critical to Gateway API’s success so far, simply in that it helps prompt everyone designing aspects of Gateway API to consider the often-conflicting needs of each role.

Likewise, explicitly defining the personas is important: it doesn’t work well to design something so that Ana can use it if we don’t agree who Ana is. In a similar vein, naming our personas has been helpful: as you’ve seen in this reply, the names prove very useful as shorthand in discussion and in design documents.

(Source: I’m the one who wrote the description of the personas that you’re reading, and I’m the one who named them.)