Documentation Link no longer works

[ledm]

Hi,

I've found that the documentation link in source/develop/recipe.rst no longer points to the correct page.

Ie:
https://github.com/ESMValGroup/ESMValTool/blob/main/doc/sphinx/source/develop/recipe.rst

points to:
https://esmvalgroup.github.io/ESMValTool_Tutorial/05-preprocessor/index.html

which no longer exists.

It should instead point to:

https://esmvalgroup.github.io/ESMValTool_Tutorial/06-preprocessor/index.html

[zklaus]

@ESMValGroup/userengagementteam

[valeriupredoi]

thanks @ledm - I have transferred the issue to https://github.com/ESMValGroup/ESMValTool_Tutorial/issues

[ledm]

It's not in the tutorial, its in the docs. This should remain in ESMValTool, not in the tutorial.

[valeriupredoi]

yes but it documents the Tutorial

[ledm]

But the code that needs to be fixed is not in the tutorial repository, it's in esmvaltool...

[valeriupredoi]

the problem affects the tutorial users, you usually open an issue in the repository whose users are impacted by the proposals in the issue, if the issue needs code/documentation changes elsewhere (in other projects/repositories), you keep the issue where it's best to be seen by the users that get impacted, and open a Pull Request in the other project/repository to make changes there, linking the issue. Does it make sense to you?

[zklaus]

I'm not sure I am buying this logic in general; I would have an issue where the problem is, perhaps an additional tracking one where it shows up to users.

But regardless, I do think it is important in this case to keep the tutorial and the documentation meshed and we might need to work on the connections between the editors of the tutorial (mostly the userengagement team?) and the editors of the documentation (all contributors?).

[rswamina]

I am in agreement with @ledm - I dont think this is a tutorial issue even if a member of the user engagement team is responsible to fix this and the problem relates directly to changes in the tutorial. I think it should remain in ESMValTool.

[valeriupredoi]

guys, come one now - this was a one liner fix, and rather than spending time on where the issue should be, how about the fix 😁 See and review ESMValGroup/ESMValTool#2473 please 🍺

Here's the thing about the best spot for the issue: the Tool documentation points to the Tutorial, so someone who is interested only in the Tutorial and gets there from the documentation is currently not able to get there - then they go see if there's any issue with the Tutorial, so they check the Tutorial Github project and see no issue was raised, they open an issue and say e.g. "Tutorial documentation on Preprocessor broken", w/o checking ESMValTool issues, so now we have duplicate issues and unhappy users. On top of that, the Tutorial people may want to perform some more fixes related to this type of issue, and they check more often the Tutorial issues than ESMValTool issues (prob not the case with us since you guys here check both repos regularly, amiright? 😁 - but you catch my drift, if these were completely separate projects maintained by separate people). So bottom line: issues should be where their best exposure is, PRs should be where the actual code lives 🍺

[valeriupredoi]

Also, me creating that PR now is a good example of why the issue should be here, and the PR should be in Tool and fixed by Tutorial people - so they can also check if other links are broken, see if anything else related can be improved. I did the bare minimum and fixed only that broken link. Having said that, I am at fault since I am a Tutorial developer too 😁