Tensorflow addons promotion and TF

[bhack]

Please take an overview of tensorflow/tensorflow#33945 (comment)

Can we document somewhere that new ops PR on Tensorflow duplicating TF addons implementations can pass through a small RFC proposal here (so that we include Addons removal or migration in the proposal)?

Currently we have tensorflow/addons#774 that was approved directly inside the SIG but here we don't have any process documented on the TF Team side.

That PR was derived from a ticket discussed with @karmel @ewilderj at tensorflow/addons#686

[karmel]

I'm not quite sure I understand-- is it correct that you want a policy on the TF side that requires an RFC for any op that is also available in addons? Or just a general policy from the TF side?

[bhack]

Yes I meant that we have a policy on the SIG but not a policy on the TF side.

I think it could be easier if somebody try to bypass Addon to directly upstream TF for the TF team to route here at "community" for propose a "small overhead" RFC that eventually will include the superseed of the Addons impl.

It would be also clear-up a little bit what will be the evaluation process on TF side.
I don't know if TF team will evaluate on the same metric set by the SIG in tensorflow/addons#774.
Also cause by an operational point of view we don't have regular metrics for the quantitative ones (like the first one in the list).

[bhack]

/cc @seanpmorgan

[bhack]

Probably we could use a specific PR template to lower the overhead of this fast RFC and to self-check early if It Is in good compliance with TF team eval migration parameters.

I don't know if you have a smooth process.

[seanpmorgan]

Probably we could use a specific PR template to lower the overhead of this fast RFC and to self-check early if It Is in good compliance with TF team eval migration parameters.

I don't know if you have a smooth process.

A PR template sounds like a good idea. I'm slightly worried about how different they will need to be for TF-core and for Keras... perhaps you'd be willing to create example templates and we could discuss the differences?

[bhack]

@seanpmorgan It would be ideal but I don't know if we could achieve that goal.
The requirements could diverge cause "de facto" for a prespective RFC merge we are passing the maintainer-ship baton to two different teams (Keras/Tensorflow) which could have two different public requirements to get it in charge.
The scope of this ticket is to have a more transparent and ant-stalling RFC process based on understandable metrics/evaluation on the "receiver" side.

[bhack]

I try to propose an actions list that could build up a generic infra also for the upstream process:

• Create a github PR template here for "upstream" type RFCs (the template will define the fields that are needed for the TF-core team to looking for a sponsor)
• Select a standard deadline interval "waiting for a TF sponsor" phase (1 month, 2 month ?)
• Create a new project if the current kban states don't overlap with "upstream" RFCs ones.
• Find a way to promote RFC to TF core team (tf-devel mailing list, internal meeting, what else?)
• Find a quantitative metric about popularity to fill-in in the template:
  • a research metric like Google scholar h5-index | Mediana h5 or citations?
  • a community metric like Create TFA OSS Usage Analyzer addons#236? But we don't know how to go ahead on that topic.

At the end of deadline we could have two outcomes:

• we found a sponsor: the PR could be merged and an implementation PR could be prepared with another PR removing the component in the SIG repository
• we didn't find a sponsor: the PR will be closed with a specific tag and the maintainer-ship will remain in the SIG perimeter.

Other kind of metrics that we talked about in the meeting could be more or less hard to be filled in the template e.g.:

• Stability?
• Complexity?
• History (how many months/days the component is in the SIG repository)? Could we define a threshold?

[bhack]

We are working on #241 for the upstreaming/promotion
And we have a new ticket for downstreaming at #242 that I hope will open a new RFC template PR like for the upstream process.
I am closing this please reopen if needed.