<commit_before># tf-api-owners review practices

## Overview

This is an attempt to gather commonly discussed topics when doing tf-api-owners
reviews. It’ll hopefully be a useful resource to both API owners and people
proposing API changes.  Process TF API Owners meet twice weekly to discuss
changes. We try to get to PRs on the next meeting, but we don’t always make it
all the way through. If your change is particularly urgent, please ping the PR
to notify us of any urgency.

## Process

We only look at changes which have already been approved by other reviewers. If
there are major outstanding comments, we will wait with API review until those
are resolved. If there are questions for API owners, explicitly raise this in
the comments to get an answer.


## High level points

### Backward and forward compatibility
We avoid backwards-incompatible API changes. We also avoid
backwards-incompatible behavior changes, such as restricting the set of valid
inputs to a function or extending the set of valid outputs of a function. Adding
support for previously not supported behavior is okay, as are changes to
explicitly experimental APIs (within reason). When needing to provide a new or
different behavior, we strongly prefer a new version of the API over breaking
backwards compatibility. Note that we are free to deprecate APIs; we just cannot
break code which relies on their documented behavior. We need to worry about
backward compatibility both of our python APIs and of the serialized GraphDefs,<commit_msg>s/tf-api/owners/ tensorflow/api-owners'<commit_after>#  tensorflow/api-owners review practices

## Overview

This is an attempt to gather commonly discussed topics when doing API
reviews. It’ll hopefully be a useful resource to both API owners and people
proposing API changes.  Process TF API Owners meet twice weekly to discuss
changes. We try to get to PRs on the next meeting, but we don’t always make it
all the way through. If your change is particularly urgent, please ping the PR
to notify us of any urgency.

## Process

We only look at changes which have already been approved by other reviewers. If
there are major outstanding comments, we will wait with API review until those
are resolved. If there are questions for API owners, explicitly raise this in
the comments to get an answer.


## High level points

### Backward and forward compatibility
We avoid backwards-incompatible API changes. We also avoid
backwards-incompatible behavior changes, such as restricting the set of valid
inputs to a function or extending the set of valid outputs of a function. Adding
support for previously not supported behavior is okay, as are changes to
explicitly experimental APIs (within reason). When needing to provide a new or
different behavior, we strongly prefer a new version of the API over breaking
backwards compatibility. Note that we are free to deprecate APIs; we just cannot
break code which relies on their documented behavior. We need to worry about
backward compatibility both of our python APIs and of the serialized GraphDefs,
{'fraction_non_alphanumeric': 0.030974894033257254, 'fraction_numerical': 0.0, 'mean_word_length': 4.5883424408014575, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3068717', 'n_tokens_mistral': 715, 'n_tokens_neox': 686, 'n_words': 484}