One way we could increase engagement is by having a regular post that shows off what we’re working on and what changes have landed. The target audience would be our non-technical users, so the main things showcased would be UX/UI changes, performance improvements, and new features. Essentially, it could be a pared-down version of our release notes.
Process
I understand that it’s tricky and difficult work to compose a blog post. It can be difficult to both track what’s going on and difficult to translate commits into average terms. I’d like to propose a process for this:
-
At the start of the month, and issue is posted on this repo as a call for materials. The issue is then sent out to our mailing lists and posted on the GNOME Discourse. Within this issue, our developers can post things they think fit on the issue. For visual changes screenshots or screencasts are encouraged. For simplicity, the guidelines should be looser than those for our release notes, e.g. plain or default wallpaper and at least a 1080p screen.
-
Over the next 3 weeks of the month, developers will have time to post things as they are completed. “Completed” should typically mean “merged”, but if there’s consensus/approval from maintainers and design team in-progress work could be allowed. At the start of the third week a reminder should be posted on the mailing list and Discourse thread that the final week is approaching.
-
At the end of the third week, submissions will be closed. Anything completed after that point will need to go in the next month’s post. The submissions will be compiled and proofread over the next week, and the post can go up either at the end of the current month or within the first week of the next, depending on how long it takes.
-
The calling for submissions should go up either when the last one is finished or the blog post is up.
Categorization
When organizing the blog posts, there are a few ways I can see working for us:
-
“Teams” - each change is organized into what team/app it came from. Shell changes go under a “Shell” header, GNOME Music changes go under a “Music” header, etc.
-
“Categories” - this is a plain one. Categories could be ui/ux, performance, and features. Each change would be under one of those headers, with various projects mixed together.
Distribution
This post should go on either gnome.org or the Engagement blog. Preferably gnome.org as the “official” space.
Why?
Currently we don’t have a good way to communicate ongoing development in a non-technical fashion. planet.gnome.org blogs tend to be very heavy on technical details or backend changes. Instead of users learning from our facilities, they learn from other avenues like phoronix, fossbytes, and more that often have misinformation or control the narrative around various changes. In addition, our reputation could improve if users could see how much work we put into improving GNOME each cycle.
This is a mirror of the proposal I posted on GitLab. Feel free to post concerns/thoughts in either place.