[DOC] review of developer documentation

[fkiraly]

Umbrella issue to collect feedback and user journeys in relation to getting set up as an open source contributor (or developer) to pytorch-forecasting.

[julian-fong]

I am having difficulty trying to find any technical documentation on how to setup a development environment on how to contribute to the library, is there a technical page detailing this anywhere in the docs? I suppose we should link that (if it exists) to the contribute page on the docs header

[fkiraly]

I am having difficulty trying to find any technical documentation on how to setup a development environment on how to contribute to the library, is there a technical page detailing this anywhere in the docs? I suppose we should link that (if it exists) to the contribute page on the docs header

Indeed I think that does not exist. This would be much appreciated!

Adding material like that to the "contribute" page, potentially inspired by sktime docs, would be a good start, although more of a band-aid. The sktime page for this is also not perfect, in the past people have gotten confused which installation workflow to follow. Perhaps we can re-design both at the same time to streamline the contributor experience?

[julian-fong]

Sure! That sounds like a good idea. Do you perhaps have an outline that I should follow to ensure that no details are missed in order to get a fully working development installation? Or maybe any specifics on what is confusing on the sktime docs so that I can try and make it more clear for both pages

[julian-fong]

I've opened a PR to add a couple minor changes here: sktime/sktime#7339

[julian-fong]

@fkiraly are you familiar with poetry? I'm not exactly how it is supposed to work with developmental installations of pytorch-forecasting. the instruction step is as follows: "To contribute, fork and clone the repository, install depdencies with poetry install, create a new branch from master such as feature/my_new_awesome_model, write your code and create the PR on GitHub.".

[fkiraly]

@julian-fong, sorry for the late reply, missed this.

I am familiar with poetry, it is primarily used to pin versions exactly or to narrow bands, for maximum reproducibility in professional development of containers, applications, or end-to-end solutions.

While it works really well for this use case, it works less well for component software (like pytorch-forecasting or sktime), especially if there is a large contributor base. It may still be used to pin developer environments, but narrow compatibility ranges for components (as opposed to applications) are counterproductive.

We have actually removed poetry now due to the maintenance burden arising from the pinned dependencies and their dependencies. I would suggest that in the documentation we replace the poetry based workflow with a basic pip based one, like in sktime.