Jean-Baptiste Kempf (12022-08-19):
> Exactly. This is called the bus-factor and is important in all
> volunteers open source communities.
> 
> Which is why the norm is "show us the code" and not wait for future
> things.
> 
> Because as we are volunteers working when we can, shit happens in real
> life, so you cannot block a project with future plans until they are
> done. Because maybe it's a 6months time or a 2 years time, or never.
> And then you never ship your software.
> For the same reason, something "ready to merge, not optimal but better
> than the current state" is Always better than "I'll do an optimal
> solution in 3 years". Especially since the first solution does not
> block the latter one.

I do not agree with this absolutist statement. There is a balance to
find between quick-and-dirty solutions that make further enhancements
harder and vague plans on the comet.

Anyway, this does not apply to AVWriter since the only things it is
blocking are my own projects. Also, AVWriter is in greatest part done.

> Therefore, I don't think those plans documents are useful: "show us
> the code!".

Try this with your plumber: “Show me my shower fixed and I'll pay you if
I'm satisfied.” It does not work that way, you have to sign a sales
quote before the plumber gets to work. This is the kind of mechanism I
want to find for FFmpeg.

I have asked you to clarify your previous suggestion:

Are you suggesting that I propose the headers and documentation for
AVWriter, that we discuss it and hopefully push it before investing more
time in the implementation?

Please answer.

Regards,

-- 
  Nicolas George