Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introduce guide-based section like Text and prompting and others
What
This is a first step towards updating readme. The update will follow multiple guidelines.
Focus on "how to do it with our SDK" instead of "what it is"
Platforms become filled with information and we wouldn't be able to keep up. Let's leave explanations of concepts to guides and API reference, and link to them whenever needed. We could think of it in a way that OpenAI's guides and API Reference are sources of truth. They have all the instructions, explanations and example. We just have to cover the part they don't have: how to do it in Swift.
Use Guides as a reference for structuring
The idea here is that a lot of APIs share concepts, and taking API Reference instead of Guides as a reference could lead to a lot of duplication in our Readme.
The Guides have such a structure:
They cover concepts regardless of an endpoint a concept is applied to. We could do the same. Something like this:
Use Guides as a reference for contents
Each Guide has focus on the main stuff that would be required for a feature/concept to run. They also have good examples that highlight different aspects. We could follow their accents and examples closely, like "with our SDK you would do it like this ...". Like on the screenshots below - an example from Structured Outputs guide turned into an example of how to use
JSONSchemaDefinition.jsonSchemain our code.Focus on one side, but don't forget about another
A lot of things here have multiple sides:
If we'd cover all the sides in each section, we'd have to many text in the readme.
I'm thinking about going like this:
Why
Users seem to be having problems with our doc.
The file gets too big and hard to read and navigate.
To be able to keep up easier with the additions.
Affected Areas
README.md