> I don't see why these are features at all. Surely it's better towards
> the end of each release cycle for someone to compare the versions of
> packages and add something in the release notes for each major GUI /
> programming language / user application that got a big update.
>
> Rich.
>
I only have a comment relative to the release notes. I agree that the release notes are the appropriate place to 'feature' changes that might not meet the requirements of a 'Feature' . Comparing the version numbers is even relatively easy - we use a script for the Technical Notes that parses repository sqlite meta data and effectively spits out the fully formed TNs.
This doesn't scale well to the verbose content expected in the release notes. A human still needs to identify changes, apply context, interpret scope and write the actual content. Determining what should be included and what changed is labor intensive.
There are several mechanisms for a developer to get their work into the release notes. The rel-notes BZ tag was wholly unused during this cycle, to the best of my knowledge. There were no bugs filed against the release-notes bugzilla product to request inclusion. When no emails were sent to the Docs mailing list, we put out a request on devel-announce for developers to get in touch; the only person that responded already had a well composed Feature page for us to work from.
So here's my suggestion :
The guidelines for Features, however they turn out, should direct developers to contacting the Docs team in some way if the feature requirements are not met. We can still give our hard working contributors the appropriate exposure, but there are *far* more developers than docs maintainers and we need their help.
--Pete
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
