[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora Tour



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 redhat com
> 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]