-
Notifications
You must be signed in to change notification settings - Fork 126
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
Conversation
Note I renamed folder and the actions bot is now generating 404 links 🔍 Preview links for changed docs |
Co-authored-by: Lisa Cawley <[email protected]>
Yay, splendid that you're spearheading this, @leemthompo ! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First review pass!
- **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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair, can revisit :)
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a candidate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shoot! :D
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this 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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this 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 |
There was a problem hiding this comment.
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.
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
contribute
sectionReviewers
URL preview
Note
Previews: #2229 (comment) (ignore comment bot links)