The artist-programmer barrier and krita

[Hologram]

Now that you mention it, you remind me of a couple things. Should have thought of this earlier

Discourse
The first is posting development updates right on Discourse. McNeel does this for its Rhino software, which, I think, a nice way to communicate what has been committed to the ‘nightly’ version of Rhino. It has a dedicated category for it’s forum for development work in progress. So if there was a ‘Work in Progress’ category on this forum, that’s where I would consolidate all topics for Krita’s development.

Inside this category, there’s a pinned topic with the list of features that is used as target for the next version release, see: Rhino WIP Features - Serengeti (Rhino 8 BETA) - McNeel Forum
Each targeted feature is split up into its own topic, when work on the feature commences. These topics are titled: Rhino [version] Feature: [Feature name].

This is a rather elaborate way to list these, but it also helps as an index
for the user to find topics of interest.

So topics like @tiar’s Planned changes to assistants coming in 2022 (or later) could live in this new category, but would be renamed to “Krita Nightly: Planned changes to assistants”.

This makes the development topics easy to identify from the home page of the forum,
because they have the same naming convention.

Then there is a pinned topic for commit logs, split to Bugs, features and crashes, see: Rhino 8 WIP Available Now! - #59 by brian - Serengeti (Rhino 8 BETA) - McNeel Forum.

From this users can easily tell if a certain bug was fixed and when. Since all of these development topics end up in this forum, the forum becomes a more prominent place than it already is. Users would see these topics pop-up in their read list if a new post was made or on the home page.
So it’s easy to set notifications the way you prefer.

Artists feedback & testing would concern general non-current development topics for existing features and the like, whereas Feature requests, would be for new features.

Roadmap
As for a roadmap, I have always liked the 3ds Max format. It is rather vague in terms of when things are going to be implemented, so it’s nice for indicating the overall direction of the software without over-promising things.
The roadmap indicates delivered features, Work in Progress features (that should be in the nightly build) and future targets. For reference, see: 3ds Max Product Enhancements, Benefits & Roadmap | Autodesk

3ds Max also has this timeline on the website to show feature implementation (could have a splash-screen image there), see: 3ds Max Product Enhancements, Benefits & Roadmap | Autodesk. I think that the main thing I would change to the existing time-line/ roadmap is that it should start from the present and go back to the past. What has recently been delivered/ worked on is more important to the user than the stuff from 2016 or earlier.

In that sense, yes, the weekly reports aren’t that important. It’s the commits that I would like to follow.