Ask here to become a member of the documentation group.
- Login or register to post comments
- 1760 reads
- Flag as offensive
- PDF version
Done, thanks.
I'm up for it. I'd really like to write some pages on the effects and transitions if possible.
Done, thanks.
I would like to post some video guides about kdenlive effects , transitions etc
I prefer to use no sound (is that ok ? ) but i will provide a brief description in text
Thanks in advance
Ok, I updated your permissions. No problem if you make tutorials without audio!
regards
Thanks
Could you please add me as a documentation writer as well? i probably won't have time to document for a few weeks, but i'd like to be in the system already when i do get a free moment and the documentation urge strikes.
also, i have some tweaks to the book module CSS and PHP code which i use for documentation on my personal home drupal. i can send patches if you are interested.
thanks
ray
I can probably help out with documentation - as soon as I figure out things work, which is hard because there isn't much documentation . . . Anyway, sign me up.
Hi,
I have some experience in writing documentation and I think I could probably contribute something.
However, before getting onto content, I think a framework might be in order- but who do I discuss this with? When I say 'framework', I don't mean some scary chapter and verse structure, what I'm thinking of is that probably a task-based approach would be helpful. Generally, developers are good at documenting their own work- i.e. "on this screen you enter these parameters which plug into the capture algorithm...", which is great and very necessary; but there's also a place for the howto approach of "To capture a video from your camcorder, follow these steps...".
I don't think it should take too long for a few right-minded people to bash out a set of task headings (wouldn't this be what some people call a workflow?) and 'hey presto', there's the framework...
Is anybody with me?
Regards,
M.
As of today, the approach is : pick-up an issue, the first who makes it wins. Then ask for help and try to make a team.
For example, this thread:
http://www.kdenlive.org/forum/i-cant-select-any-solved
I asked to write a short howto explaining why codecs where missing and how to install them.
Now way, it does work. I had to write the three lines myself.
As a conclusion, I would recommand that you modify the documentation step-by-step, in a way that it is never broken or unreadable, until you reach a suitable result.
Okay, your approach is good; it's also compatible with mine! All I'm saying is that, once a howto has been written, it can be placed in a framework so that people can find it. Your example would go somewhere around the introduction, perhaps under a heading "Okay, I've installed Kdenlive and it doesn't work..."
Obviously, not all parts of the framework will be filled in to begin with (perhaps not even very many), but it can fill up over time. And if anyone has a bit of time on their hands and is wondering where to direct their documentation energies, they can look at the framework and see what sections are empty(/iest).
Regards,
M.
The only rule is that when you start a small project, you have a commitment to finish the work. This is why working on small batches is somehow more interesting.
Just a suggestion or two, regarding your online image/PR ...
Perhaps somebody might like to help to update this wikibook?
http://en.wikibooks.org/wiki/Kdenlive
There are a number of out-of-date sites like this...
http://liquidweather.net/howto/index.php?id=112
- would it be worth the effort to get in touch with such site owners and update them?
In general, if you want as many 'customers' as possible you'll need to make sure that casual browsers looking for a new editor gain the most favourable impression possible of the product... although it will probably pan out just fine on the basis of "if you build it they will come" if it does the job :)
As an ethusiastic user of kdenlive, the only real downside has been the lack of proper documentation. So I'd like to help remedy that, and offer to author some documentation.