veyepar: Tech writing in a continuous deployment world

Hi user

Admin Login:

Name: Tech writing in a continuous deployment world
--client eric --show wtd_na_2015 --room crystal_ballroom 9722 --force
Prev: 11 Designing Information for Growth
Next: 11 Keynote: The Federated Wiki

show more...

Author(s):	Christine Burwinkle
Location	Crystal Ballroom
Date	may Mon 18	Days Raw Files
Start	16:50	First Raw Start	16:44
Duration	00:30:00	Offset	0:05:12
End	17:20	Last Raw End	17:21
Chapters	00:00
Total cuts_time	27 min.

http://lanyrd.com/2015/writethedocs/sdmwyf/
raw-playlist raw-mp4-playlist encoded-files-playlist host public tweet mp4 svg png

final audio

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

State:
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:	has someone authorised pubication
Normalise:
Channelcopy:	m=mono, 01=copy left to right, 10=right to left, 00=ignore.
Thumbnail:	filename.png
Description:	Here at Atlassian, we’ve been moving ever closer to a world of continuous deployment for our software products. Five years ago, releases took months. Now, many products are releasing every two weeks at a minimum. In addition, the past year has seen features being deployed as soon as they pass testing. What’s a tech writer to do!? In true agile fashion, the response to these challenges varies across products and writers within Atlassian. This gives us a breadth of stories and examples I can share about our experiences in this world. Here’s a high-level look at what I’ll share: A brief discussion of continuous deployment: what does it mean, especially for tech writers and others involved in the process? A look at some things that have worked for us. Making the mental shift from releases to features has been an absolute necessity. We’ve also had to change the tooling we use, the processes we follow, and the way we communicate. This journey has also forced us to consider what the documentation equivalent of an MVP (minimal viable product in Agile development) looks like. There are a few things that haven’t worked out very well! Resource-heavy deliverables (like videos and tutorials) are really difficult to maintain. Communication also increases in importance in a rapidly-paced cycle. These and other areas provide us with some good lessons learned. The jury is still out on a few experiments! Things like investing more heavily in in-app help and automating doc publication in tandem with code deployment are among the experiments we’re attempting to get better at this new world. markdown
Comment:	production notes

2015-05-18/16_44_48.dv Apply: 16:44:48 - 16:54:31 ( 00:09:43 ) S: 16:44:48 - E: 16:54:31 D: 00:09:43 show more...

vlc ~/Videos/veyepar/eric/wtd_na_2015/dv/crystal_ballroom/2015-05-18/16_44_48.dv :start-time=00.0 --audio-desync=0

	Raw File	Cut List
	16:44:48		seconds: 0.0 Wall: 16:44:48
Duration	00:09:43
	16:54:31		seconds: 0.0 Wall: 16:44:48
Comments:
mp4 mp4.m3u	dv.m3u	Split: Sequence:: delete

audio viz

2015-05-18/16_54_32.dv Apply: 16:54:32 - 17:21:36 ( 00:27:04 ) S: 16:54:32 - E: 17:21:36 D: 00:27:04 show more...

vlc ~/Videos/veyepar/eric/wtd_na_2015/dv/crystal_ballroom/2015-05-18/16_54_32.dv :start-time=00.0 --audio-desync=0

	Raw File	Cut List
	16:54:32		seconds: 0.0 Wall: 16:54:32
Duration	00:27:04
	17:21:36		seconds: 0.0 Wall: 16:54:32
Comments:
mp4 mp4.m3u	dv.m3u	Split: Sequence:: delete

audio viz

Rf filename:	root is .../show/dv/location/, example: 2013-03-13/13:13:30.dv
Sequence:
get this:	check and save to add this

2015-05-18/16_44_48.dv
audio viz

audio viz

2015-05-18/16_54_32.dv
audio viz

audio viz

Veyepar Video Eyeball Processor and Review