Author(s):	Lana Brindley
Location	T101
Date	jan Wed 18	Days Raw Files
Start	15:40	First Raw Start	error-in-template
Duration	1:50:00	Offset	None
End	17:30	Last Raw End
Chapters
Total cuts_time	None min.

http://lca2012.linux.org.au/schedule/61/view_talk
raw-playlist raw-mp4-playlist encoded-files-playlist mp4 svg png

assets release.pdf How_good_are_you_really_Improving_your_technical_writing_skills.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:	--------- borked edit encode push to queue post richard review 1 email review 2 make public tweet to-miror conf done
Locked:	clear this to unlock
Locked by:	user/process that locked.
Start:	initially scheduled time from master, adjusted to match reality
Duration:	length in hh:mm:ss
Name:	Video Title (shows in video search results)
Emails:	email(s) of the presenter(s)
Released:	Unknown Yes No has someone authorised pubication
Normalise:
Channelcopy:	m=mono, 01=copy left to right, 10=right to left, 00=ignore.
Thumbnail:	filename.png
Description:	Even the most hardcore open source developers need to write documentation to go with their code. Whether it's design specifications, code comments, a reference manual, or the entire user guide, having good documentation can mean the difference between people using and contributing to your code, or throwing it away as a bad joke. Lana has been writing open source technical documentation for over five years, and is now inviting you to come along and learn about why open source projects require the best possible documentation. During the first half of the tutorial, we'll go over why documentation is so important for open source projects, what the hallmarks of good writing are, and some examples of both good and bad writing. The second half of the tutorial will be applying the lessons we've learned to your own writing to improve it, and learning how to apply those skills to future writing tasks. Bring a writing sample of your own for improvement. It can be documentation related to any current project you are working on: design and planning documents, end-user documentation, user interface or help text, or even commented code. markdown
Comment:	production notes