Graduating (addon2core) and de-graduating (core2addon) policies

[bhack]

#550 (comment)

/cc @ewilderj / @seanpmorgan @karmel

[karmel]

The policy thus far has been somewhat adhoc, but the pieces are in place to define a more formal policy. We could say something like, if we want to push something to Keras, submit an RFC to keras-team/governance, and go through the standard review. For pulls from Addons, what would you prefer, @seanpmorgan ? An issue? An RFC?

This won't solve the problem in the linked thread, though, which is that the desire for features manifests in many places. What did you have in mind, @bhack ?

[seanpmorgan]

Yeah this is certainly a process that we want to formalize but it's a bit tricky. I like the idea of all Keras migrations going to keras-governance as an RFC. Going forward we'll make that the procedure for Keras migrations.

Do we have thoughts for things that don't fit as Keras API (e.g. some of our image processing functionality?) Is a tensorflow/community RFC too much?

Regarding tracking we've started this process with this document on the root of our repo:
https://github.com/tensorflow/addons/blob/master/MIGRATED_TO_CORE.md

We spoke with some contributors and we think a GitHub project is a better tool to use instead of a static document. Anyone know if we can link keras-goverenance RFCs in that project even though the repo is outside of our organization?

EDIT --- Also as Karmel said... open to suggestions for a way to consolidate requests

[karmel]

A TF RFC (acronym bingo!) for non-Keras things would be great. It doesn't have to be very heavyweight, but I think it's a very good practice to get into.

[ewilderj]

RFCs don't have to be long. Would rather we had more than less.
cc/ @theadactyl @joanafilipa

[bhack]

Image processing or in general image namespace it Is another confusing topic.
I.e. check tensorflow/graphics#107

I think we need to unify the stuff a little bit if we don't want the newcomers to be confused in a multirepository pinball.

So I'am for unify RFC in TF community repo and relaxing RFC verbosity threshold if it is needed to lowering the overhead.

[bhack]

I'am propose to start to put Keras issue in read only mode relatively soon and start, with the community support, to add extra labels for Keras issue bot migration to Tensorflow repo.
We can agree over few extra labels to classify the ticket for the migration mini-bot (ignore, migrable, etc..).