feat: add sphinx project's basic configuration and structure to deploy on RTD

[mariajgrimaldi]

Description

This PR adds a Sphinx project's basic configuration and structure to deploy on RTD. The docs structure is based on a simplified version of: https://internal.docs.edunext.co/en/latest/internal/Processes/Knowledge_management/LandD/templates/tech_products_doc_template.html

To generate the docs in your local environment, please do the following:

1. make requirements
2. make docs
3. Go to docs/build to find the docs index

I'll ask for help internally to deploy it in our RTD domain :)

[MaferMazu]

I only have one comment left, but the rest looks good! ✨

Thanks for this.

I think we need some documentation about how a member of edunext can build right now, but this repository is probably not the best place for that. Probably we want to edit this for future work: https://internal.docs.edunext.co/en/latest/internal/Products_and_Services/by_products/picasso/picasso-v2.html?highlight=picasso%20v2#how-to-build-with-picasso

[mariajgrimaldi]

@MaferMazu: I agree. I'll be doing that next. Thank you!

[magajh]

Looks great!

Just out of curiosity, why are we adding the documentation for this product on a separate subdomain instead of the main public documentation: https://public.docs.edunext.co/en/latest/? I’m not sure if there was already a conversation about this and I missed it, so I apologize if that’s the case

[mariajgrimaldi]

@magajh, thanks for raising this. No, this was more of a deliberate decision I made based on what we have for TVM, although they're completely different tools (TVM is OS community-oriented, whereas this is not).

Still, I think docs must be hosted in the same repository as the implementation to keep a single source of truth. In that case, edunext-internal-documentation must pull the docs from this repository so it's included in the build directory deployed on RTD. I'll have to dig more to see whether that's feasible. If not, we'll have to move the documentation to another repository, which we can discuss if you think that's a better approach.

@MaferMazu @magajh: What do you think? We could still test this approach and revise it later.

EDIT: I was reviewing the Shipyard Product, which consists of various tools similar to Picasso. However, I didn't find specific docs for the drydock tool since the documentation is hosted within the same repository (mainly the readme file), which is what I wish to maintain, at least for the workflow specifications. I'll be thinking about the best way to tackle this.

[mariajgrimaldi]

@MaferMazu @magajh: what do you think about externally linking this documentation from our internal docs? We've done the same with several of our products like plugins (see internal docs Our products > Edunext Open source Extensions)

[MaferMazu]

@mariajgrimaldi I like the idea, but I'm unsure about the right place in the 'internal doc'. I will suggest the Picasso product. (We can ask Wanda)

But as I said before. We still need documentation about how a member of edunext can build with GA. Something like this: https://internal.docs.edunext.co/en/latest/internal/Products_and_Services/by_products/picasso/picasso-v2.html?highlight=picasso%20v2#how-to-build-with-picasso

We can also edit that document to have the instructions and link to this repo doc in RTD.

[mariajgrimaldi]

@MaferMazu: I'm sorry I wasn't more specific. When I said internal doc, I referred to the section meant for the Picasso product, as is done for the eox's documentation that refers to each repository. We can still ask Wanda, but I think that would be a good place.