docs: create page for key concept scheduling

[HonkingGoose]

Changes:

• Create page for key concept scheduling
• Adjust pages that mention scheduling so that they have links to the key concept page if needed
• Remove/rewrite sections of other pages that mention scheduling, so the docs as a whole remain cohesive

Context:

Helps with issue #11237 but does not close it, as more work is needed.

TODOs:

Search for these words to see if other pages need fixing:

• timezone
• schedule
• @breejs/later
• minutes
• hours
• days

Edit the following pages:

• FAQ, control renovate's schedule
• deep dive dependency pinning, scheduling section
• configuration options, check things related to time, schedule, @breejs/later, minutes, hours, days
• deep dive, noise reduction via scheduling

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please tick one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[HonkingGoose]

I could also add the other key-concepts files as a placeholder with this PR if we want.

[rarkins]

Are you suggesting that we put this "empty" page live on the docs site already? If not, can you describe what you suggest?

[HonkingGoose]

Are you suggesting that we put this "empty" page live on the docs site already? If not, can you describe what you suggest?

I'm trying to figure out what's the best way to work on this. As this is a major rework it will move a lot of stuff around and change a lot of stuff. I don't know what's the best approach.

Option 1: add placholders so they're ready to go. Gradually move stuff into placeholders.
Option 2: do all key-concepts in one go.
Option 3: something else that's better.

I hate dealing with merge conflicts, so I'm trying to find a good way to organize my work. So that I prevent having main moving under me while I work. If I make a PR that moves stuff on main when merged, and meanwhile people open PR's targeting files on main I keep having to fix stuff before I can get my own work merged. 😄

So if you have any good ideas, please tell me! 😄

[rarkins]

I was thinking we can do one key concepts page at a time. Dashboard is already there: https://docs.renovatebot.com/

[HonkingGoose]

I was thinking we can do one key concepts page at a time.

I'll do them one at a time then! I'll start with the key concept of scheduling. 😉

[rarkins]

Does this replace any existing pages?

[HonkingGoose]

Does this replace any existing pages?

That is the plan!

The FAQ has a section on Control Renovate's schedule, which I'm going to replace with just a link to the finished key-concepts/scheduling.md file. This reduces duplication.

https://docs.renovatebot.com/faq/#control-renovates-schedule

---

I'm not sure why we have a section on scheduling in the deep dive for pinning JavaScript dependencies.
Since this is related to scheduling, I'd like to fix this in this PR as well...

We mention that npm packages can be unpublished, and say that scheduling is the solution, but we now have the stabilityDays and eventually "merge confidence" to fix this problem, so the schedule is not the proper solution anymore.

What do you want me to do with this section?

https://docs.renovatebot.com/dependency-pinning/#scheduling

[rarkins]

I think that section is OK to leave as-is, but link to the new scheduling page too.

[HonkingGoose]

Let's confirm the direction we want to take this in before I make further changes. 😉

[HonkingGoose]

@rarkins Should I move the ## Scheduling Renovate and ### Selective Scheduling sections into my new key-concepts page?

Link to page: https://docs.renovatebot.com/noise-reduction/#scheduling-renovate

If I move those sections, the rest of the noise-reduction page needs a slight rewrite as well.

[rarkins]

I think that article is weakened by removing too much. Links are just not the same

[HonkingGoose]

I agree that we shouldn't weaken the existing articles, but we run the risk of duplicating ourselves across multiple files if we keep things as-is...

Let's take a step back and discuss which topics we want to cover in the key-concepts/scheduling.md file, and which we're happy to cover in more detail elsewhere.

I think (at least) the following topics should go in the key concepts page:

• Explain Renovate default schedule (basically updates as soon as they come in), explain that Renovate uses UTC timezone
• Explain how to customize schedule, and set your own timezone for the schedule
• Explain that we have schedule presets that can help
• Explain how to set a schedule for a specific package(s)
• Other things that I'm forgetting to list

Let me know what your vision is for this page! 😉

I'm sorry for causing a lot of back and forth with you, but better we discuss this properly before I need to revert all of my work because I misunderstood things. 😄

[rarkins]

I think start with the topics you have listed there, and let's put it live!

[HonkingGoose]

I made some changes, but it's still tricky to explain the different Renovate schedules....

The overall setup seems to be:

• Admin determines when Renovate bot runs on the server (cron), for GitHub app users, @rarkins is the admin...
• If user is not admin, then they can customize when Renovate will check for updates via either a schedule preset, or by writing their own packageRules

I'm not sure if this is properly explained in the text we have now....

[renovate-release]

🎉 This PR is included in version 26.13.2 🎉

The release is available on:

• GitHub release
• 26.13.2

Your semantic-release bot 📦🚀