There are a couple of changes I was expecting to see in the F23 Alpha (such as Python-3-as-default and dnf based system upgrades), which aren't mentioned in the current release notes. It would be good if the Alpha release notes covered the state of the approved system wide changes that are still *intended* to land by the Beta release, so it's clear which changes are still in progress (and may need help with testing), and which have been postponed to the next release. This could be in a separate specific-to-the-Alpha-releases section of the release notes aimed at Fedora contributors, rather than being part of the release notes in general.
When you say 'the current release notes' what are you referring to? We do not provide release notes for alpha and beta releases, and we are still working on the release notes for Fedora 23 (both features that you pointed out will be included).
I mean release announcements like the one in Fedora Magazine: http://fedoramagazine.org/fedora-23-alpha-released/ That doesn't tell me: * Why might I want to try out the Alpha? * What still needs help getting to the line for Beta? * What should be I paying particular attention to as a likely source of issues? Even a list of "Here are the links to the changes we're working on release notes for" would be good, with the release notes themselves visibly evolving throughout the alpha/beta cycle.
As noted in bug #1258094, I think the pre-release announcements are also a potentially good opportunity to seek new contributions to the release notes.
I was in the room for Joe's talk you mentioned in #1258094, and interjected at least once to make the distinction between "Release Announcement" and "Release Notes"; as much as I could without derailing his talk. They are two discrete works, each with a different target audience and scope. To address your point directly, the currently shipped version of the Fedora Release Notes, available in the fedora-release-notes package from the F23 repos, does discuss contributing to both relnotes content and pre-release QA. These release notes don't discuss any release-specific features, at all. I agree with your points in general. It would be nice if documentation kept in sync with development, and users could easily find all the info they're interested in, and guidance to info on work in progress. There's room for discussion and opportunities for contribution, whether under the Marketing/Magazine tent or at the Docs beat writing desk. You're welcome participate in discussions of improving processes, and welcome to participate in content development, but that conversation doesn't make sense in the context of a bug report. Please mail docs.org or marketing.org, depending on which area you'd like to help improve. In either case, you'll probably find that instead of a considered omission, the amount of content available corresponds with the amount of volunteer time available, and be invited to directly improve the areas of your concern.