You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+20-5Lines changed: 20 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -53,7 +53,21 @@ import {
53
53
54
54
The `method-engine` export is intended for reusable APIOps workflow logic. It gives CLIs, AI agents, apps, and APIs the same station recommendation, resource lookup, and canvas generation behavior without reimplementing the method rules.
55
55
56
-
Sticky note authoring should uses the shared palette exposed by the method engine:
56
+
The method now also includes reusable stakeholder data:
57
+
58
+
-`src/data/method/stakeholders.json` defines the shared stakeholder catalog
59
+
-`src/data/method/station-stakeholders.json` maps each station to weighted stakeholder participation
60
+
-`src/data/method/<locale>/labels.stakeholders.json` stores localized stakeholder titles, descriptions, and involvement labels
61
+
62
+
Stakeholder involvement uses three lightweight levels:
63
+
64
+
-`lead`
65
+
-`core`
66
+
-`consulted`
67
+
68
+
This is meant to keep APIOps Cycles explicitly cross-functional, including business, security, compliance, support, and consumer voices in architecture and design work where relevant.
69
+
70
+
Sticky note authoring should use the shared palette exposed by the method engine:
57
71
58
72
-`benefit`: `#C0EB6A`
59
73
-`neutral`: `#DFDDC5`
@@ -88,16 +102,17 @@ If you spot a problem in the documentation or have an idea for new content, plea
88
102
89
103
### Editing or adding content
90
104
91
-
The main method content files (instructions, guidelines, method structure) are located in the the JSON files at `src/data/method/`. These base files (`lines.json`, `stations.json`, `resources.json`, `criteria.json` and `station-criteria.json`) are not localized and live at the root of the folder. Textual values in them reference label keys. English labels are in `src/data/method/en-US` and translations are provided in `labels.lines.json`, `labels.stations.json`, `labels.resources.json` and `labels.criteria.json` under each locale folder. Some longer or more complex resource pages like the API Audit Checklist also use markdown snippets `src/snippets/` linked to the `resources.json`. Do not use any frontmatter in the snippet files. Any supported markdown markup is ok. See references from [Starlight markdown reference](https://starlight.astro.build/guides/authoring-content/) and [Extended markdown reference](https://www.markdownguide.org/extended-syntax/).
105
+
The main method content files (instructions, guidelines, method structure) are located in the JSON files at `src/data/method/`. These base files (`lines.json`, `stations.json`, `resources.json`, `criteria.json`, `station-criteria.json`, `stakeholders.json`, and `station-stakeholders.json`) are not localized and live at the root of the folder. Textual values in them reference label keys. English labels are in `src/data/method/en` and translations are provided in `labels.lines.json`, `labels.stations.json`, `labels.resources.json`, `labels.criteria.json`, and `labels.stakeholders.json` under each locale folder. Some longer or more complex resource pages like the API Audit Checklist also use markdown snippets `src/snippets/` linked to the `resources.json`. Do not use any frontmatter in the snippet files. Any supported markdown markup is ok. See references from [Starlight markdown reference](https://starlight.astro.build/guides/authoring-content/) and [Extended markdown reference](https://www.markdownguide.org/extended-syntax/).
92
106
93
-
Each station links to specific entry criteria followed by the next core station's criteria as exit criteria.`criteria.json`, `station-criteria.json` and `labels.criteria.json`
107
+
Each station links to specific entry criteria followed by the next core station's criteria as exit criteria. Stakeholder participation is modeled separately through `stakeholders.json`, `station-stakeholders.json`, and `labels.stakeholders.json`.
94
108
95
109
#### Editing existing content of Method pages (metrolines, core- and substations, resources).
96
110
1. Go to `src/data/method/en` and edit the content in English (English is considered the master langauge, and for the translations to work for other languages, it must always be the first to be edited).
97
111
2. Validate that your changes work by running the schema validations (`npm test`)
98
112
3. Follow the translation guide if you are able to translate the content to other languages manually or automatically.
99
-
4. Commit your code and make a pull request.
100
-
5. If you were not able to create the translations of your changes to all languages, create an issue for in the repository for the translations.
113
+
4. Update all supported locales before considering the change complete. This includes criteria wording and stakeholder labels when those are touched.
114
+
5. Commit your code and make a pull request.
115
+
6. If you were not able to create the translations of your changes to all languages, create an issue in the repository for the translations.
101
116
102
117
#### Translating the language manually or with automated services (new or existing languages with new or changed content)
assert.equal(localizedStakeholders.length,entries.length,`Localized stakeholder count mismatch for ${station.id}.`);
29
+
assert.ok(localizedStakeholders.every((entry)=>entry.title&&entry.description&&entry.involvementLabel),`Incomplete localized stakeholder data for ${station.id}.`);
assert.ok(Array.isArray(designData.stakeholders)&&designData.stakeholders.length>0,"Expected stakeholders in station resource data.");
41
+
assert.ok(designData.stakeholders.some((entry)=>entry.id==="security-specialist"),"Expected api-design to include security-specialist.");
42
+
assert.ok(designData.stakeholders.some((entry)=>entry.id==="compliance-legal-specialist"),"Expected api-design to include compliance-legal-specialist.");
43
+
assert.ok(designData.stakeholders.some((entry)=>entry.id==="business-owner"),"Expected api-design to include business-owner.");
assert.ok(architectureData.stakeholders.some((entry)=>entry.id==="security-specialist"),"Expected api-platform-architecture to include security-specialist.");
47
+
assert.ok(architectureData.stakeholders.some((entry)=>entry.id==="compliance-legal-specialist"),"Expected api-platform-architecture to include compliance-legal-specialist.");
"description": "Relevant stakeholders agree this API opportunity is worth exploring and prioritizing."
17
17
},
18
18
{
19
19
"id": "api-opportunity-documented",
@@ -25,11 +25,11 @@
25
25
},
26
26
{
27
27
"id": "hide-backend-discrepancies",
28
-
"description": "The goal of the API is to hide backend data models and discrepancies."
28
+
"description": "The API is intended to shield consumers from backend complexity and inconsistencies."
29
29
},
30
30
{
31
31
"id": "value-prop-validated",
32
-
"description": "The value proposition validates with key stakeholders."
32
+
"description": "The API value proposition has been reviewed and validated with the relevant business and consumer stakeholders."
33
33
},
34
34
{
35
35
"id": "consumer-segments-identified",
@@ -41,46 +41,46 @@
41
41
},
42
42
{
43
43
"id": "architecture-patterns-validated",
44
-
"description": "The API architecture uses patterns that promote reusability and integration, and is validated with stakeholders."
44
+
"description": "The chosen API architecture and platform patterns have been validated with the relevant architecture, security, and platform stakeholders."
45
45
},
46
46
{
47
47
"id": "design-reflects-business-value",
48
-
"description": "The API's design and endpoints have a clear connection to their business value and features."
48
+
"description": "The API design and exposed capabilities clearly trace back to business value and user needs."
49
49
},
50
50
{
51
51
"id": "api-consistency",
52
-
"description": "API has a consistent design with our other API products."
52
+
"description": "The API design follows our shared API product and design conventions."
53
53
},
54
54
{
55
55
"id": "api-contract-tested",
56
56
"description": "The API contract is tested and meets functional and non-functional requirements."
57
57
},
58
58
{
59
59
"id": "api-description-available",
60
-
"description": "The API and its endpoints have descriptions that explain their business value and features."
60
+
"description": "The API and its exposed capabilities are described clearly enough for review, audit, and onboarding."
61
61
},
62
62
{
63
63
"id": "audit-passed",
64
64
"description": "The API passes compliance, security, and audit checks."
65
65
},
66
66
{
67
67
"id": "audit-reports-shared",
68
-
"description": "Audit reports are shared with stakeholders."
68
+
"description": "Audit findings and remediation decisions are shared with the relevant stakeholders."
69
69
},
70
70
{
71
71
"id": "api-ready-for-publishing",
72
-
"description": "The API is ready to be published to the appropriate gateways and environments to support reusability for multiple API consumers."
72
+
"description": "The API is ready to be deployed and exposed through the intended gateways and environments."
73
73
},
74
74
{
75
75
"id": "api-documentation-ready",
76
-
"description": "API documentation is complete and ready for publishing."
76
+
"description": "Consumer-facing API documentation is complete enough for publishing and onboarding."
77
77
},
78
78
{
79
79
"id": "consumer-support-ready",
80
-
"description": "API registration, support, and communication processes are in place."
80
+
"description": "Registration, support, and communication processes are ready for API consumers."
81
81
},
82
82
{
83
83
"id": "legal-compliance-clear",
84
-
"description": "Legaland compliance requirements are precise enough for publishing."
84
+
"description": "Legal, privacy, and compliance requirements for publishing are defined and understood."
"criterion.metrics-feedback-available": "Erkenntnisse aus Metriken und Feedback stehen zur Optimierung bestehender APIs zur Verfügung",
4
+
"criterion.metrics-feedback-available": "Relevante Marktsignale, Feedback oder operative Erkenntnisse sind verfügbar, um diese API-Möglichkeit zu steuern.",
5
5
"criterion.business-goals-defined": "Geschäftsziele sind definiert",
"criterion.stakeholder-approval": "Relevante Stakeholder stimmen zu, dass diese API-Möglichkeit es wert ist, sie zu erkunden und Priorität einzuräumen.",
8
8
"criterion.api-opportunity-documented": "Individuelle API-Möglichkeiten werden identifiziert und dokumentiert",
9
9
"criterion.api-reusability": "Die API erfüllt einen klaren Geschäftsbedarf und ist für mehrere API-Nutzer wiederverwendbar",
10
-
"criterion.hide-backend-discrepancies": "Das Ziel der API ist es, Backend-Datenmodelle und Diskrepanzen zu verbergen.",
11
-
"criterion.value-prop-validated": "Das Wertversprechen wird mit den wichtigsten Stakeholdern validiert.",
10
+
"criterion.hide-backend-discrepancies": "Die API ist dazu gedacht, Verbraucher vor Backend-Komplexität und Inkonsistenzen zu schützen.",
11
+
"criterion.value-prop-validated": "Die API-Wert proposition wurde mit den relevanten Geschäft und Verbraucher-Stakeholdern überprüft und validiert.",
12
12
"criterion.consumer-segments-identified": "API-Nutzersegmente (intern und extern) werden identifiziert.",
13
13
"criterion.api-roadmap-defined": "Hochrangige Roadmaps für die API-Entwicklung werden erstellt.",
14
-
"criterion.architecture-patterns-validated": "Die API-Architektur verwendet Muster, die die Wiederverwendbarkeit und Integration fördern, und wird mit den Stakeholdern validiert.",
15
-
"criterion.design-reflects-business-value": "Das Design und die Endpunkte der API stehen in klarem Zusammenhang mit ihrem geschäftlichen Nutzen und ihren Funktionen.",
16
-
"criterion.api-consistency": "Die API weist ein einheitliches Design mit unseren anderen API-Produkten auf.",
14
+
"criterion.architecture-patterns-validated": "Die gewählten API-Architektur- und Plattformmuster wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert.",
15
+
"criterion.design-reflects-business-value": "Die API-Design und die offengelegten Funktionen spiegeln klar den Geschäftswert und die Bedürfnisse der Benutzer wider.",
16
+
"criterion.api-consistency": "Das API-Design folgt unseren gemeinsamen API-Produkt- und Design-Vorgaben.",
17
17
"criterion.api-contract-tested": "Der API-Vertrag wurde getestet und erfüllt die funktionalen und nicht-funktionalen Anforderungen.",
18
-
"criterion.api-description-available": "Die API und ihre Endpunkte verfügen über Beschreibungen, die ihren geschäftlichen Nutzen und ihre Funktionen erläutern.",
18
+
"criterion.api-description-available": "Die API und ihre offengelegten Funktionen sind ausreichend beschrieben für Überprüfung, Auditierung und Onboarding.",
19
19
"criterion.audit-passed": "Die API besteht Compliance-, Sicherheits- und Audit-Prüfungen.",
20
-
"criterion.audit-reports-shared": "Auditberichte werden mit den Stakeholdern geteilt.",
21
-
"criterion.api-ready-for-publishing": "Die API kann in den entsprechenden Gateways und Umgebungen veröffentlicht werden, um die Wiederverwendbarkeit für mehrere API-Nutzer zu unterstützen.",
22
-
"criterion.api-documentation-ready": "Die API-Dokumentation ist vollständig und bereit zur Veröffentlichung.",
23
-
"criterion.consumer-support-ready": "Prozesse für die API-Registrierung, den Support und die Kommunikation sind eingerichtet.",
24
-
"criterion.legal-compliance-clear": "Die rechtlichen und Compliance-Anforderungen sind für die Veröffentlichung präzise genug."
20
+
"criterion.audit-reports-shared": "API-Auditberichte wurden mit relevanten Stakeholdern geteilt.",
21
+
"criterion.api-ready-for-publishing": "Die API ist bereit, für Verbraucher verfügbar gemacht zu werden.",
22
+
"criterion.api-documentation-ready": "Die API-Dokumentation ist vollständig und für die Veröffentlichung und das Onboarding geeignet.",
23
+
"criterion.consumer-support-ready": "Registrierungs-, Support- und Kommunikationsprozesse sind für API-Nutzer bereit.",
24
+
"criterion.legal-compliance-clear": "Rechtliche, datenschutzrechtliche und Compliance-Anforderungen für die Veröffentlichung sind definiert und verstanden."
0 commit comments