Happy to see you work on this 
We already discussed these things in person, so I’m just gonna give feedback on what I see on the page – and the relating Module Roles page.
Landing Page
Clear roadmaps are important, but last time we tried that it didn’t work out well. I’m talking about the roadmap images where we outlined projects to work on for the next releases. IMO it was a mistake to make the roadmaps release based, rather than project based. After 2.8, devs agreed to switch to a process that’s more focused on merging features once ready, not based on releases and release cycle deadlines.
There was a discussion with proposals here: Proposal to remove module roadmap images.
(BTW, in the past Ton raised the point that the module page on the Wiki should contain more info about the module. Devs seem to be more in favor of using the developer.blender.org project pages for such info, so better check with Ton what he thinks of this.)
QA Members
The addition of QA as one of the (if not the) main responsibility of artist members seems to have been added some weeks ago, with no public notice of it (e.g. no announcement in the notes of that week or before/after).
This is a significant change in the role, and it puts the artists into a much more reactive, much less proactive position. Having some role for QA may be quite helpful, no doubt. But the IMO most important role for artist involvement isn’t really addressed anywhere now. That is, we need competent users who can help us create better designs in the first place. Designs that follow a coherent bigger picture while being highly practical. For that, they need to be involved from the first day of a project until a product is well polished and evaluated sufficiently.
Maybe this role should be filled on a per project basis, not on a per module basis. But having them actively involved in modules already makes things much easier (we know where to find the artists and they don’t need to find their way around first). Either way, this role is missing in the organization currently.
On another note, if you lookup QA job descriptions, these are usually quite “dry” jobs. It involves lots of work with measurements, protocols, automation, statistics, … Even if we keep it more basic, I doubt that we will find anywhere close to enough artist members that are enthusiastic enough about testing basic functionality all day long with no artistic outcome. At least not volunteers.