Requirements for a feature staying in the repo

[gabrieldemarmiesse]

This is to track the work necessary to do on features already there.

A feature should:

• Have a proper docstring
• Have a link to the paper it comes from in the docstring.
• Be displayed in the documentation
• Have an API which correspond to the one used in keras (eg. use lr for the learning rate in optimizers)
• Be in a single file
• Have unit tests
• Those unit tests should be in a single file too.
• Those unit tests should run in the CI system (here travis).
• Those unit tests should run with theano, tensorflow, cntk, tensorflow.keras. (or have a strong reason to skip one of them).
• Should NOT be added automatically to the custom object of keras.
• Only use the keras public API (otherwise it won't work with tf.keras)
• Have a codeowner for the feature and the tests in the CODEOWNERS file.

Features which do not respect this will be removed / not included in this repo.

Otherwise, we'll end up like tensorflow.contrib :(

[titu1994]

Should NOT be added automatically to the custom object of keras.

While the other requirements make perfect sense, may I ask what is the reasoning behind this requirement?

[gabrieldemarmiesse]

We should avoid to modify global objects at import time. This is highly unexpected by users.

Also the documented way of using custom objects is to use either a context or to use the keyword argument custom_objects.

See:
https://keras.io/getting-started/faq/#handling-custom-layers-or-other-custom-objects-in-saved-models
https://www.tensorflow.org/api_docs/python/tf/keras/utils/get_custom_objects

[titu1994]

Ok that makes sense.

[gabrieldemarmiesse]

I hope we can make a cool v1.0 :)

[titu1994]

Yes, its been a long time coming for this contrib repo. :D