Description of problem: There needs to be better (more complete) documentation of changes in new Fedora Core releases. Many of us do not have the time or knowledge to understand the functionality changes which have been incorporated into a new release. The individuals knowledgable of the changes should add documentation to the RELEASE-NOTES or a "What's New" document. Case in point which appeared on the fedora-list mailing list: RHL9 shipped with gnome 2.2 whereas FC1 ships with gnome 2.4. In 2.4, the configuration of the panel has changed dramatically and folks on fedora-list were wondering if something was broke or just how to configure things ... nothing was broke, it was just different. While I realize that folks do not read the RELEASE-NOTE who should because it answers their questions, they cannot read that which does not exist. Expecting individual users to go out and find that change documentation for all the packages is just not reasonable. BTW, this "should" be filed against the fedora-release package but that package name is not available under bugzilla.
Another example of something that needs documentation is menu editing under gnome. By default, editing of menus is disabled. However, if you replace /etc/gnome-vfs-2.0/modules/default-modules.con with /etc/gnome-vfs-2.0/modules/default-modules.conf.with-menu-editing then you can edit the menus. Currently, the only "documentation" I am aware of are some email messages.
(Moved to fedora-release, as bugzilla has updated its package list for Fedora Core) Thanks for your submission. We are working on a number of changes to the release notes creation process that will hopefully improve the quality of the release notes. Specifically, we are restructuring the release notes to make it easier for both users and developers to find things; hopefully this will encourage more developer feedback -- it will be easier for them to determine what is being said about "their" software. We are also going to use bugzilla as a means of tracking and discussing release notes content. This should reduce the problems inherent in the current email-based process (namely the lack of a single place to discuss each specific issue). However, keep in mind that this is likely not going to completely solve the problem. While you are correct that the people responsible for any changes to functionality (namely, the developers) should ideally be responsible for ensuring that this change in functionality gets documented, the reality is that, for a number of reasons, this is not always the case. Short of forcing developers to write stuff at gunpoint, nothing is going to get 100% compliance; the best we can hope for is to increase compliance as much as possible. I'm going to close this with a "deferred" status, as although the changes are in progress, it will be a while before we find out how effective the changes have been. Feel free to re-open it if you have additional observations/suggestions.