On Tue, 2005-12-13 at 13:05 -0500, Jeff Spaleta wrote: > we might need to consider > pulling in a variant of mplayer which is legal to house in Extras to > get this job done. I have no idea about the technical merits of mplayer, but they do a good job with supporting codecs. Is the work to make such an mplayer package and get it accepted upstream something we can handle ourselves? What can we offer the Mplayer developers to get them to do or accept any necessary changes? These sort of FLOSS economics are interesting to me. How do we get disparate islands working together? Our combined skills and agendas are more powerful than just cash ... right? > > 3. Where do we coordinate this work -- what infrastructure do we need? Do > > we upload files to the wiki? Do we put them in CVS? > I don't think there is much in the way of needed infrastructure needed > beyond the wiki and applications in Core and Extras. > > I think we need to agree on system configuration to use as a baseline > for videos so videos will be "similar" enough to make a consistent > picture. You'd like to avoid things like different menu items across > videos for the collection of videos that are meant to be a Core tour. > For non-tour one-off topics the desktop state can be allowed to vary a > bit. I think though for a "tour" you want it to be somewhat seamless > as a single video even if there are individual chapters. This is one reason FDP is involved. We see this as content and under our purview, at least to defining standards, support infrastructure, providing editorial and publishing services, and coordinating with translation. We need to define the standards in quick iterations. As we test iterations of a working toolset, we'll pass the output through to f-docs-l for peer review. From that come updates to the Fedora Documentation Guide. If package maintainers are in short supply, we may have interested people who want to expand into that roll. > > 4. Who does the voice-overs in different languages? > shrug.. hopefully native speakers for each language. Yes, we should have a timed script with precise timing and rhythm that a native speaker can launch from. They go through the video a few times and work up a synchronization. Would that work? > > 5. What's the final format? > theora, is there another reasonable choice that works out of the box? +1 > > 6. Can it all be driven by volunteers? :) > I don't see why not. +1 > > Here's how I think it should work initially. +1, good iterative formula. We can peer review to f-docs-l instead of burdening Rahul. He'll speak up anyway. ;-) > Choose a particular > "scene" from the tour that you want recorded. Can we prioritize these scenes in terms of importance for production? I think that using pup is an obvious first, updating systems is key. For the rest of this, let's move the script generation discussion to f- docs-l. There's writers there who may be interested in developing the script and running the project. - Karsten > Write up english > instructions, a script, that can be followed by video creators to > "shoot" the scene. Let a couple of people shoot the scene and > designate someone, (Rahul!!!!!!) to pick the best video from the > contributed ones or edit the script and let people re-shoot. Once a > reasonable video is in hand, move on to voice-overs, where people > speak a version of the script as an audio track. > > If this works with one scene > Proposal for a test scene: "Updating your system with pup" > Scene begins just after gnome login is completed, last user action was > interacting with the > gdm login screen. > Scene ends with the desktop in a state as close to the starting state > as possible. > > -jef > > -- > Fedora-marketing-list mailing list > Fedora-marketing-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-marketing-list -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-marketing-list mailing list Fedora-marketing-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-marketing-list
