On 2021-02-02 12:29, Michael Koch wrote:
Another suggestion: A programmer who adds a new feature to FFmpeg
shouldn't write the documentation for this feature himself. Because
for him everything is totally clear and he forgets to describe some
important details. It's better if someone else tests the new feature
and writes the documentation.
I think this is a great idea.
Also, if the developers of FFmpeg want to commit to better documentation
for FFmpeg, they could make a policy that new code changes go into
feature branches, not directly into master. Then someone writes the
corresponding documentation which describes the changed feature
behaviour, to the quality and accuracy level the project expects for
documentation, and checks that into the feature branch too. Only when
the code is in the branch and reviewed, *and* the documentation is in
the branch and reviewed, may be branch be merged into the master branch.
This policy would require an initialisation condition, because many
parts of the documentation are probably not up to whatever quality and
accuracy level the project demands. The initialisation condition needs
to provide a way for the documentation to catch up to the present code,
and trade this off against slowing down the rate of change in the code.
Developers of FFmpeg could commit to better testing also, by making a
similar policy for unit test fixtures. I believe that FATE does not
validate all of the important behaviours of the code at the moment.
—Jim DeLaHunt
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
