Skip to content

Latest commit

 

History

History
48 lines (27 loc) · 3.1 KB

CONTRIBUTING.md

File metadata and controls

48 lines (27 loc) · 3.1 KB

Contributing to the Gemini API Cookbook

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.

Before you send anything

Sign our contributor agreement

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.

Style guides

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.

Making changes

Small fixes

Small fixes, such as typos or bug fixes, can be submitted directly via a pull request.

Content submission

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.

Things we consider

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.

Attribution

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.