[FFmpeg-user] "instead of complaining, submit a patch" [was: Re: minterpolate problem]

[Jim DeLaHunt]

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