> That is correct, and it would be sad and damaging to believe exhausted volunteer maintainers should satisfy each and every desire of yours.

That's precisely why I am keeping silent. I worked on OSS myself and I don't want to come off as entitled. When I don't find the features that I would like I am mostly just shrugging and thinking to myself "either I'll research Zola's code base and make a good PR about it or I'll just keep my thoughts for myself because everyone can demand their own favorite features and it's not a productive use of the maintainers' time to read people's wishlists".

> However, stating expectations and desires respectfully is really helpful, especially when it is done in a precise manner so someone with time and energy can try to implement it.

True to an extent but I've been bitten by this in the past. My definition of respectful expectations is somebody's idea of entitlement even if I use language like "please consider this feature if you find yourself with some extra bandwidth in the future" and "I think this would help adoption because I know I am not the only one wanting it" and "this could help with SEO for this or that class of websites".

I learned that many OSS maintainers are tired and jaded -- and thus very jumpy as a result. So I just stopped giving suggestions after I have been slapped with "only PRs are welcome, otherwise we are not interested in theoretical discussions" several times in the past.

I realize Zola's maintainers might not be like this but there's something else to consider as well: it's mentally very tiring to have to use extremely watered-down diplomatic language (almost to the point of begging) just so you don't get on somebody's bad side if they had a crappy day.

I've had people rage at me for saying something as simple as: "feature X would be very helpful for workflow Y, would you consider adding it during the next 6 months?" (I guess the trigger was the implication of a deadline imposed on somebody's hobby work but the reaction was violent enough that I lost my desire to apologize.) And so it goes.

> We usually use a version control system (like git) for that.

I don't know the specifics but wouldn't that require Zola's Rust code to be aware of the GIT history of the website itself? Sounds like 5 tons of complexity loaded on top of 10kg worth of software, so to speak -- but I might be wrong.

I'd personally go for something like this:

    /articles/
      /reasons-to-choose-rust-in-2021/
        + 2020-01-31.html
        + 2020-02-28.html
        + 2020-03-05.html
      why-i-left-ruby.html
      /resume/
        + 2019-01-17.html
        + 2020-03-15.html

^ The above describes only 3 articles, one of each has no revisions (why-i-left-ruby.html), one of them has two revisions (resume) and another has three (reasons-to-choose-rust-in-2021).

However, I am just talking out of my a$$ and can't comment if this is easy to integrate or what complexity and repercussions would it have to the otherwise free-form directory/file structure that Zola encourages.

I am simply illustrating what I would be after.