The OpenAI Cookbook is a community-driven resource aimed at sharing knowledge in a way that is accessible, engaging, and enriching for all AI builders.
Before contributing, read through the existing issues and pull requests to see if someone else is already working on something similar. That way you can avoid duplicating efforts.
Generally, we have found that the best contributions to the Cookbook are useful, novel or creative, or a combination of these.
- Useful: Involves concepts or techniques that can be applied broadly and often, and can translate to practical use-cases and solving real-world problems. If you're doing something often, chances are others are too, and having reusable examples to reference can be very helpful.
- Novel: Showcases new developments or techniques. Look out for new research on how to best use LLMs, or new models and capabilities in the API.
- Creative: Uses LLMs in creative and innovative ways, or combines multiple APIs and tools in novel ways.
Additionally, we strive to maintain a neutral tone, and aim for high quality writing.
- Neutral: Maintains a neutral stance on tools and products. While it's natural to have preferences for particular tools, a good guide avoids over-evangelizing or marketing specific products, ensuring integrity and inclusivity.
- High quality: Well structured, clear and complete. Writing good content ensures others can fully benefit from it. See the rubric below for more details on how we assess the quality of submissions to the Cookbook.
To ensure the quality of submissions, we have established a rubric that assesses each contribution on various areas. The purpose of this rating system is to maintain a high standard of quality, relevance, and uniqueness. Each area is rated on a scale from 1 to 4. Contributions that score lower than a 3 in any of the areas will generally be rejected.
We encourage contributors to familiarize themselves with this rubric before writing content. Understanding the criteria not only increases the chances of your contribution being accepted, but also helps in creating a resource that is comprehensive, clear, and beneficial for all users.
For additional advice on writing good documentation, refer to What Makes Documentation Good.
| Criteria | Description | Score |
|---|---|---|
| Relevance | Is the content related to building with OpenAI technologies? Is it useful to others? | |
| Uniqueness | Does the content offer new insights or unique information compared to existing documentation? | |
| Clarity | Is the language easy to understand? Are things well-explained? Is the title clear? | |
| Correctness | Are the facts, code snippets, and examples correct and reliable? Does everything execute correctly? | |
| Conciseness | Is the content concise? Are all details necessary? Can it be made shorter? | |
| Completeness | Is the content thorough and detailed? Are there things that weren’t explained fully? | |
| Grammar | Are there grammatical or spelling errors present? |
| Criteria | 4 | 3 | 2 | 1 |
|---|---|---|---|---|
| Relevance | Relevant and useful. | Relevant but not very useful. | Tangentially relevant. | Not relevant. |
| Uniqueness | Completely unique with fresh insights. | Unique with minor overlaps. | Some unique aspects, but significant overlap. | Many similar guides/examples. |
| Clarity | Clear language and structure. | Clear language, unclear structure. | Some sections unclear. | Confusing and unclear. |
| Correctness | Completely error free. | Code works, minor improvements needed. | Few errors and warnings. | Many errors, code doesn't execute. |
| Conciseness | Cannot be reduced in any section, or overall. | Mostly short, but could still be reduced. | Some long sections, and/or long overall. | Very long sections and overall, redundant. |
| Completeness | Complete and detailed. | Mostly complete, minor additions needed. | Lacks some explanations. | Missing significant portions. |
| Grammar | Perfect grammar. | Correct grammar, few typos. | Some spelling/grammatical errors. | Numerous spelling/grammatical errors. |