Add documentation on serde

[bolkedebruin]

This adds documentation for developers on how to use serde and when to apply it.

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[potiuk]

Looks cool.

I am not sure we need to add separate section and whether it should be put in "airflow.apache.org" documentation.

I believe generally for quite long time we've been following the patter to separte the "developer/contributor" documentation from user documentation.

It used to be that these two types of docs were intermixed In airflow.apache.org - but over last few years you will find that we moved most of this documentation to files that live in GitHub repository, while leaving the airflow.apache.org to users.

There might stil be a few of those docs in airlfow.apache.org, and there is a little overlap wiith https://airflow.apache.org/docs/apache-airflow/stable/public-airflow-interface.html (which are stll list all the things that Airlfow users and Provider developers can rely on as public), the detailed documentation lives in the code, usually close to the code the documentation describes.

Few examples (some of them are really starting points and need a lot more love - like your document does)

• https://github.com/apache/airflow/blob/main/airflow/providers/MANAGING_PROVIDERS_LIFECYCLE.rst
• https://github.com/apache/airflow/blob/main/tests/system/README.md
• https://github.com/apache/airflow/blob/main/airflow/METRICS.md
• https://github.com/apache/airflow/blob/main/airflow/sensors/README.md

Benefit of doing it is that they can be linked to "main" version in GitHub - not to the "stable" version of Airflow (the latter being updated far less frequently and tied with specific version). Also we can then refer to the documentation from the code of Airflow (for example in exceptions etc.).

Also both .md and .rst are natively rendered by GitHub, so it's really nice way of sharing the developer docs.

So seems like natural place for this kind of doc is

https://github.com/apache/airflow/tree/main/tests/serialization/README.rst maybe?

[bolkedebruin]

Haha, a nice way of saying, why did you not look over there ;-)

[potiuk]

Haha, a nice way of saying, why did you not look over there ;-)

Well. IF the exception where serialization failed would point to the docs in GitHub and explain "go there and read how you can fix the problem (maybe)", then it's likely that someone (not ncessarily me) who had no idea that it can be done this way would look here.

So adding documentation is one thing, dragging attention and directing the contributor (and maintainers) to the place increases the chances of success if our goal is "let's use serde approach for similar cases" - if that's the goal.

Then it does not matter where it is ...

[eladkal]

I believe generally for quite long time we've been following the patter to separte the "developer/contributor" documentation from user documentation.

True. Contributor docs are not kept on Airflow site but on Github

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.