@misc,
I completely concur with what you think. We have been on this path previously as well with another one of such revamps and a discussion about JavaScript frameworks back in the day (it can be found here About JS framework - infrastructure - Fedora Mailing-Lists). What intrigues me (and scares me at the same time as well) is the fact that we might just be repeating the loop - without having much on-ground activity and thus, trapped in (what I like to call) an “analysis paralysis”.
But rewriting and maintaining are the same process of creating content, as there is a spectrum from “no constraint at all” on one side, and “this need to use that stack in that version, that css, follow that guidelines with that content” on the other.
From a newcomers perspective, these constraints would definitely look like a higher entry point to the community and from that of ours, these would be the factors why someone would refrain from working on these technologies with us. Apprenticeship is fine - but at this point in time, we are not quite in a position to offer that while possibly rewriting a huge chunk of the sites in any said frontend framework.
If the rewriting side of the spectrum is seen as more desirable (since that’s what everybody want to do each time ), we need to know why the alternatives are not.
I am too sleepy right now to be able to drop a novel sized message with a great theory, but I suspect it has to do with the agency of the people in charge, and because it seems simpler to rewrite than to learn/discover the legacy codebase (or just more fun).
We dubbed it “standardization-by-bringing-every-application-to-the-same-stack” during one of our very earliest meets but we, of course, knew where we were heading with that. It would not be wrong to state that a majority of the teammates might not know what a certain site is built on, and while it is not necessarily a bad thing - the circumstances and factors considered while making a suggestion from their end, as a result, would be superficial at best.
Having worked alongside @thunderbirdtr for some time now on the fedora-websites repo and a plethora of others with the help of other contributors, it has become quite apparent to me what can be added and what can be termed as a distant dream. I would ask folks to please consider the engineering perspective - to materialize the stilts, that the team would be rebuilding their house on.
So if you want volunteers, then what attract them (making new website) should be easy to do. If my hypothesis regarding constraints and agency is right, we need to increase the agency of the future volunteer by having the least amount of constraint, eg ruthlessly remove everything that could be seen as such.
For example, not mandate a specific build stack, just “it should generate static pages using a container”. Not mandate to use a specific footer HTML code, just “we need those links”. Not mandate a specific format and extraction of strings system for translation, just “we do not care as long as it output something compatible, and take this in input”.
We would begin with minimizing the constraints to a bare minimum of what, we cannot do without (which I think has been done by the team which has worked on previously). With the introduction of a frontend framework, we are risking adding back a lot of those constraints for our sanity’s sake but at the cost of the contributor’s participation. I am a lot inclined to make minimal changes to improve upon something that works fine, than to open up and lose all the screws/bearings while trying to fix something that is not broken in the first place.
The more constraints we have, the closer we move to the undesirable side of the spectrum. I might be controversial, but I think that a common css, a common js library, a mandatory footer (as opposed to the mandatory presence of the information) would remove some agency, and add more complexity, so might be undesirable long term.
A huge +1 to this. My practical thinking at Websites Revamp Frontend Framework - #6 by t0xic0der which I acquired with my interaction with the repositories might be seen as scepticism and I understand that, but these are the very minimum that we would want to keep in mind while discussing the short-term feasibility and the long-term viability of starting from a clean expensive slate.