Create guide to guide future UX discussions

[ESadek-MO]

📚 Documentation

From a conversation with @HGWright, @trexfeathers, and @ukmo-ccbunney.

#4799 required extensive discussion, and suffered from a very broad scope and a large code-base/doc-base.

This could be alleviated in future discussions by creating a document with some discussion points detailed, and perhaps the outcomes of previous discussions.

Some ideas are written below. Whether this page should be within our docs, or just more toned down, is yet to be decided.

Community

• How do we make it easy for our users to contribute, ask questions, and generally get involved?

Documentation

• How accessible/complete are Iris' docs?
• How easy is it to move from Iris to another package, including those within SciTools and external packages?
• How transparent are our philosophy, past development decisions, and future plans?

Codebase:

• How aligned is Iris with other packages in the wider community? e.g. common api, common jargon
• How easy is it for users to debug and diagnose code?
• Is the API as simple as possible for users to understand and access?

Finally, we should ensure that we regularly check in and make sure that no further issues are left unseen.

[ukmo-ccbunney]

From @SciTools/peloton : When Diataxis is adopted, this will sit naturally in the Explanation quadrant.
Until then adding to the "Further topics" looks like the best place for this to live.

[trexfeathers]

When we make these documentation page(s), they could include an encouragement to engage in GitHub Discussions if anything needs changing/clarifying - don't want our decisions to be set in stone for eternity.