On 5/22/13, Robert Krueger <[email protected]> wrote: > On Wed, May 22, 2013 at 6:53 PM, Brad O'Hearne > <[email protected]> wrote: >> On May 22, 2013, at 9:02 AM, Robert Krueger <[email protected]> wrote: >> >>> After all, most of the work is >>> done by people in their spare time and I haven't found many developers >>> who enjoy writing documentation (no matter how important docs are, I >>> think we all agree on that). >> >> The problem, Robert, is bigger than just finding someone to document >> FFmpeg, getting volunteers, or motivating people. The bigger problem is >> that producing good documentation and discussion of a particular technical >> domain requires an inquisitive and exhaustive approach, willing to drill >> down to details, and ask questions which put design decisions and >> potentially either weaknesses or needs in the spotlight. The tone of this >> mailing list just doesn't have a thick-enough skin for that. The discourse >> on this list consistently demonstrates an inability to treat machinery as >> machinery, nuts and bolts, and instead quickly degenerates into personal >> attacks when a good answer isn't quickly obvious, or when someone refuses >> to consider that there may be a problem in some part of FFmpeg which >> someone has adopted as their turf. >> >> There is absolutely zero question in my mind, from the several projects >> I've had to solve with FFmpeg, discussions with others, numerous blog >> posts which lament the undocumented and unknown nature of various parts of >> FFmpeg, that save bug-fixing, adding a single additional line of code to >> FFmpeg pales in importance to thoroughly documenting the API with adequate >> discussion, documenting use, and producing some examples that address >> real-world use-cases, not "let's just generate some audio samples or a >> sample images for video", which avoids the real problems of building a >> robust app. >> >> I love writing, have written technical documentation and technical >> articles, and had several book deals offered. Given my frustrations and >> time loss due to a lack of documentation, if it were mine to script, I'd >> document the whole thing myself, and produce either a book or user guide >> on this. But given both my personal experiences thus far and observing >> others as well on this mailing list, I won't go anywhere near it. Too much >> shoot-the-messenger on this mailing list. Too much condescension if you >> ask a question without demonstrating deep expertise of a particular >> concept. Too much passion for sniping people because they don't just by >> default know something. That, Robert, is the primary problem -- with >> people making personal attacks, and an inability to drill into minutia >> with patience, people who would otherwise offer their services are driven >> away. >> >> I'm not just referring to my own experiences here, I've been on this >> mailing list a year and a half, and I've watched it with others, too. It's >> a shame. Entirely unnecessary. >> >> Brad > > my last reply to that, I promise. > > For the record, in (I think) about 5 years on this list, I would say > that in about 70% of the occasions I properly documented a problem > (reproducible test case or comparable) I got help (for free). > > Have there been occasions when I thought someone could have been more > polite? Yes, but that's people and that happens everywhere. It's not > ffmpeg policy to drive people away AFAICS. Especially in the past two > years IMHO the tone has changed quite a bit (not claiming it is > perfect). > > Have there been occasions where I disagreed with things developers > have decided to do or been frustrated about it? Yes, but I am not > really a contributor so the people doing the work have their decision > making process and that's what I have to live with or go find another > project or product to get the job done.
About what you are refering to? > > Do I have my own opinion what ffmpeg should have their priorities set > to? Sure, but hey, for every person actually making something happen > in this project, there are probably at least a hundred out there > thinking they know how things should be done so I bite my tongue most > of the time. It's not my company/project and the way to get a say in > these things is contributing, it's as simple as that. There is place where everyone can open new bug/feature request report. > > Has sponsoring someone to get a problem solved worked? Yes. Maybe it > is something you can consider if you're stuck in a situation with > ffmpeg for a paid job. I guess you are still going to pay less than > you would have to, if you were licensing a commercial library by > Mainconcept et al. If you think betting on that to work is too risky > you _have_ to get a commercial alternative. > > Has complaining about the way things were run in this project by a > non-contributor ever worked making anything better? Not that I know of > and I swear, this is just meant as advice/observation not an attempt > to attack or to diss you. > > Cheers and peace, > > Robert > _______________________________________________ > Libav-user mailing list > [email protected] > http://ffmpeg.org/mailman/listinfo/libav-user > _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
