Proposed audience strategy for website refresh about cdevents.dev HOT 3 OPEN

(...)

CI/CD Tool Maintainers

As a CI/CD Tool Maintainer, I work for a commercial CI/CD Tool Vendor, or am a contributor to a FOSS project that maintains a CI/CD tool.

I am highly technical and understand the benefits of standardization and interoperability.

My primary interest is in understanding the specification so that I can implement functionality in my product correctly.

I may be a producer of events who is maintaining a CI/CD platform tool, or I may be a consumer of events who maintains an associated CI/CD product such as a metrics collection system or visualizer.

Decision-makers

I work at an End-Customer organization and am currently evaluating CI/CD tooling options in order to support our transition to Continuous Delivery.

I think we should limit ourselves here to the use case of transitioning to CD.
Many organisations are at different stages in their CD journey and they may be looking at how to advance further, how to improve on specific DevOps metrics, and how to fix existing bottlenecks and inefficiencies.

Is "End-Customer" different from "End-User"?
End-user is an organisation that adopts CI/CD tools but does not resell them.
What does end-customer refer to in this context?

I may come from a technical or a commercial background and am at an early stage of familiarity with the challenges associated with Continuous Delivery.

I need help to understand how best to differentiate between all the tooling options available to me.

End-Customer Engineers

I work at an End-Customer organization and am responsible for implementing our internal CI/CD instances.

I am technical and understand some of the challenges in the Continuous Delivery space but want to learn more about how CDEvents make my life easier.

It might be worth calling out platform engineers. Event-based architecture and flexible and resilient, but also have a higher degree of complexity, so I expect them to be more common in organisations that have a platform team managing that complexity for all the dev teams.

When a platform team exists, CI/CD engineers may still have to emit CDEvents to fit within the platform, and our documentation should be a good reference for them.

Browsing audience

I am interested in CI/CD and Continuous Delivery and am looking to understand more about best practice in this space.

I have been reading the CDF Best Practices Guide and was referred here from there. I may be more or less technical in background and would like to understand where the value in CDEvents lies for me.

(...)

from cdevents.dev.

From a best practices perspective, we discourage the use of ‘CD’ abbreviations as too ambiguous. The focus should really be on Continuous Delivery as an overarching methodology because the majority of business value is realised only via that path, so the intermediate task of continuous deployment often causes confusion and ‘failure to take-off’.

from cdevents.dev.

I like the way you describe the Audience Strategy, @tdcox !

And to expand on it event more, to me, the two main purposes of cdevents.dev site are:

1. "Storefront" - Present what CDEvents is in as simple and intuitive and convicing terms as possible, attracting potential users (CI/CD tool maintainers, decision makers and end-customer engineers) of CDEvents

• This would include some top use cases for CDEvents. Those include the obvious CI/CD tools interoperability on the orchestration level, but almost equally important is the added value of enabling any consumers of this data to digest it in a standardized way. Such consumers could be metrics collectors (DORA for example), visualization solutions, release decision processes, build/test avoidance systems, etc etc.
• The Storefront would be based on the latest released version of the CDEvents spec, if version specific information is mentioned

2. "Portal" - Serve as a portal for all CDEvents information needs, such as a link to the spec (preferrably links to all supported versions), information about existing SDKs, PoCs and other CDEvents supported tools/components (i.e. CDEvents landscape)

Of less importance is the need to include:

• Detailed technical details such as json schemas and a full catalog of event examples. Such could instead be assumed to be found in some of the referenced GitHub repos (the spec repo for example). This section should probably link to (or possibly include) information related to each supported version of the spec.

So regarding the narrative track "There is a highly technical audience that needs very detailed and accurate specifications" I believe that comes with lower priority than the above mentioned "Storefront" and "Portal" narratives.

from cdevents.dev.