diff --git a/docs/AddingCustomOp.md b/docs/AddingCustomOp.md
index b5a0a9c96f..952aad3412 100644
--- a/docs/AddingCustomOp.md
+++ b/docs/AddingCustomOp.md
@@ -15,6 +15,8 @@ Currently, the only supported Execution Providers (EPs) for custom ops registere
 
 Note that when a model being inferred on gpu, onnxruntime will insert MemcpyToHost op before a cpu custom op and append MemcpyFromHost after to make sure tensor(s) are accessible throughout calling, meaning there are no extra efforts required from custom op developer for the case.
 
+To facilitate the custom operator development, sharing and release, please check the [onnxruntime custom operator library](https://github.com/microsoft/ort-customops) project for the more information.
+
 ### 2. Using RegisterCustomRegistry API
 * Implement your kernel and schema (if required) using the OpKernel and OpSchema APIs (headers are in the include folder).
 * Create a CustomRegistry object and register your kernel and schema with this registry.
diff --git a/docs/PyOp.md b/docs/PyOp.md
index b4a5911d70..a494362205 100644
--- a/docs/PyOp.md
+++ b/docs/PyOp.md
@@ -1,6 +1,6 @@
 # Python Operator 
 
-**Deprecation Note: This feature is deprecated and no longer supported.**
+**Deprecation Note: This feature is deprecated and no longer supported, please refer to [onnxruntime_customops](https://github.com/microsoft/ort-customops) project for this function.**
 
 The Python Operator provides the capability to easily invoke any custom Python code within a single node of an ONNX graph using ONNX Runtime. This can be useful for quicker experimentation when a model requires operators that are not officially supported in ONNX and ONNX Runtime, particularly if there is already a Python implementation for the required functionality. This should be used with discretion in production scenarios, and all security or other risks should be considered beforehand.