We would love to accept your patches and contributions to the Gemini API Cookbook. We are excited that you are considering donating some of your time, and this guide will help us be respectful of that time.
All contributions to this project must be accompanied by a Contributor License Agreement (CLA). You (or your employer) retain the copyright to your contribution; this simply gives us permission to use and redistribute your contributions as part of the project.
If you or your current employer have already signed the Google CLA (even if it was for a different project), you probably don't need to do it again.
Visit https://cla.developers.google.com/ to see your current agreements or to sign a new one.
Before you start writing, take a look at the technical writing style guide. You don’t need to fully digest the whole document, but do read the highlights so you can anticipate the most common feedback.
Also check out the relevant style guide for the language you will be using. These apply strictly to raw code files (e.g. *.py, *.js), though code fragments in documentation (such as markdown files or notebooks) tend to favor readability over strict adherence.
For Python notebooks (*.ipynb files), consider running pyink over your notebook. It is not required, but it will avoid style-related nits.
Small fixes, such as typos or bug fixes, can be submitted directly via a pull request.
Before you send a PR, or even write a single line, please file an issue. There we can discuss the request and provide guidance about how to structure any content you write.
Adding a new guide often involves lots of detailed reviews and we want to make sure that your idea is fully formed and has full support before you start writing anything. If you want to port an existing guide across (e.g. if you have a guide for Gemini on your own GitHub), feel free to link to it in the issue.
When you're ready, start by using the notebook template and following the guidance within.
When accepting a new guide, we want to balance a few aspects.
- Originality - e.g. Is there another guide that does the same thing?
- Pedagogy - e.g. Does this guide teach something useful? Specifically for a Gemini API feature?
- Quality - e.g. Does this guide contain clear, descriptive prose? Is the code easy to understand?
It is not crucial for a submission to be strong along all of these dimensions, but the stronger the better. Old submissions may be replaced in favor of newer submissions that exceed these properties.
If you have authored a new guide from scratch, you are welcome to include a byline at the top of the document with your name and GitHub username.