Skip to content

Add API docs contribution guidance under extend/contribute #2229

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 19 commits into from
Jul 30, 2025

Conversation

leemthompo
Copy link
Contributor

@leemthompo leemthompo commented Jul 23, 2025

Reviewers

  • Page titles could be improved
  • What's missing that we need in this first iteration?

URL preview

Note

Previews: #2229 (comment) (ignore comment bot links)

@leemthompo
Copy link
Contributor Author

leemthompo commented Jul 23, 2025

@elastic elastic deleted a comment from github-actions bot Jul 23, 2025
@elastic elastic deleted a comment from github-actions bot Jul 23, 2025
Co-authored-by: Lisa Cawley <[email protected]>
@leemthompo leemthompo marked this pull request as ready for review July 24, 2025 06:57
@leemthompo leemthompo requested a review from a team as a code owner July 24, 2025 06:57
@elastic elastic deleted a comment from github-actions bot Jul 24, 2025
@leemthompo leemthompo self-assigned this Jul 24, 2025
@theletterf
Copy link
Contributor

Yay, splendid that you're spearheading this, @leemthompo !

Copy link
Contributor

@theletterf theletterf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First review pass!

Comment on lines +100 to +103
- **TypeScript API definitions** contain JSDoc comments with descriptions, annotations, and type information
- **JSON spec files** define endpoint URLs, HTTP methods, and parameters for each API
- **Example YAML files** provide realistic request/response demonstrations
- **OpenAPI overlays** allow customization of the generated OpenAPI documents for specific consumers
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if we should use so much bold everywhere, tbh.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair, can revisit :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here's a vote to keep the bold 👍 for scannability

---
navigation_title: Find your team's workflow
---
# Find the workflow for your API docs
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is a workflow in this context? We don't define it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hate this page title TBH and "workflow" is very placeholdery 🛟

Workflow = Each team has its own process for producing their OpenAPI files in their respective repositories

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should external contributors be concerned about team structure? Shouldn't we rather talk of "products" or "areas" or "features", or simply how to find your way to the right API docs source?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/team/product 👍

Need help on the title of this page tho

How can we boil How do the different products do their API docs down into a suitably compact formulation?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a candidate

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shoot! :D

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


# Contribute to Elastic documentation

Find the relevant pages for contributing to the official Elastic documentation.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What defines Legacy and Current? How does one know?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What defines Legacy and Current? How does one know?

Basically by reading the information in the table 😄

I'm seeking to delegate to the docs-builder docs for the granularities in this first iteration, until those docs get moved here and we revisit

- Reordered sections: moved "Structure, organization, and metadata" before "Content quality and completeness"
- Removed all checkboxes and converted to plain bullet points
- Added reference to quickstart guide for previewing
- Removed validation checklist item about OpenAPI document structure

- Changed navigation title from "Find your team's workflow" to "API docs by product"
- Updated heading from "Find the workflow for your API docs" to "How each Elastic product manages API docs"
- Shifted language from "team" to "product" terminology in descriptions
Copy link
Contributor

@ketkee-aryamane ketkee-aryamane left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A good first start to this process. :))
I left some comments and questions, if you think it's nitpicking, feel free to ignore.

- **Write clear descriptions:** Explain what the example accomplishes in more detail and why it's useful
- **Include edge cases:** Show how to handle optional parameters, error conditions, and different response types
- **Point out key details:** Highlight important aspects users might miss
- **Show variations:** Demonstrate alternative approaches or related concepts
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how many do we expect? good to state clearly that they can provide happy path and any specific business cases that must be known to devs/users

Copy link
Contributor Author

@leemthompo leemthompo Jul 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if it's helpful to give a specific number, but the wording here could be improved

navigation_title: Contribute locally (Elasticsearch)
---

# Contribute locally: Elasticsearch quickstart
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like specifically for elasticsearch-specification repo. do we plan to add similar quickstarts later for other APIs since they come in with different workflows?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, I would contribute this to elasticsearch-specification directly. We have a lot of this already mentioned in README.md and CONTRIBUTING.md.

Copy link
Contributor Author

@leemthompo leemthompo Jul 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have a lot of this already mentioned in README.md and CONTRIBUTING.md.

Yes but those pages aren't really end-to-end about docs, and they are not well organized today. I at least wanted to have this E2E workflow documented in one place. We can discuss how we handle overlap going forward.

This looks like specifically for elasticsearch-specification repo. do we plan to add similar quickstarts later for other APIs since they come in with different workflows?

We needed a concrete workflow for this guidance to not be super high-level and impractical. Because the Elasticsearch APIs are our largest set, and the entire workflow isn't laid out in a step-by-step fashion anywhere, we decided that we should have this, somewhere. We have a lot of work to fix the gaps in the Elasticsearch API docs. The easier we make it for contributors to help out, the faster that will happen.

do we plan to add similar quickstarts later for other APIs since they come in with different workflows?

This is very MVP, so there isn't a super long term plan right now and yeah ultimately, maybe this page goes away and we just link to the repos in workflows.md

Copy link
Member

@pquentin pquentin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I think I see the point of having docs specifically for the docs aspect of the specification. Should we link to the Elasticsearch specification docs, such as the modeling guide?

navigation_title: Contribute locally (Elasticsearch)
---

# Contribute locally: Elasticsearch quickstart
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, I would contribute this to elasticsearch-specification directly. We have a lot of this already mentioned in README.md and CONTRIBUTING.md.

leemthompo and others added 5 commits July 30, 2025 15:30
summary of diff:

• renamed section from "document path parameters" to "document parameters"
• broadened scope to all parameter types, not just path params
• added note about explaining effect of changing defaults
• adjusted summary character count guideline (5-45 chars vs 30 max)
• simplified parameter documentation principles
• reorganized examples section for path parameters
• added clarification about default values impact
• removed elastic-employee-specific help content
• simplified api ownership reference table
• updated pipeline diagram with clearer naming
• added step about backporting changes in quickstart
• removed private repository references
• renamed workflows page title
• various minor text improvements
@leemthompo leemthompo enabled auto-merge (squash) July 30, 2025 15:20
@leemthompo leemthompo merged commit 639e08d into main Jul 30, 2025
8 of 9 checks passed
@leemthompo leemthompo deleted the leemthompo/api-docs-contrib branch July 30, 2025 15:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants