Some projects include in the readme some mentions of goals and non-goals. And I also think it is pretty sane and transparent for both the mantainers and the users that these explanations exist.

Might also be a product of experience, that you have a need for strict scope definitions.

When I was unexperienced, I would actively look for projects I could do and features to add to them. Because well, most project ideas were too large for me to tackle anyways and I needed the experience.

Now that I have experience, I have multiple long-term projects that could use some love, if I find the time. And I have the experience to tackle virtually any project idea, if I find the time.

Don't particularly want to add another long-term project into the rotation, so I do spend a lot more time thinking upfront "when will this be finished?".

I rarely even add readmes or licences, I like writing code, not polishing it.

I haven't done this, but I think this idea is going to stick with me going forward

As software engineers, an SRS doc is a very good friend of ours. just create a standard SRS doc and link to it in the readme.

I always start my projects with the SRS

I always start with defining requirements, and then I follow with a bunch of pseudo code. Its how I do things at work too. I like getting the ideas and structure out before I write any actual code or I get stupidly distracted.