[MPlayer-dev-eng] User Frendly mplayer

[Diego Biurrun]

Ivan Kalvatchev writes:
 > 
 > You see that reading manual is the last step. What could be done:
 > 1. Write (short) README and INSTALL files. Add things like from
 > where to download additional packages (divx4linux,ffmpeg, faad,
 > mad etc...). README with text like : "Read 'War And Peace' before
 > installing mplayer" is not the right one.

I will write a short "Quickstart Guide" and post it to -users to see
if it is easy to understand.  We can put it in CVS later as README or
INSTALL or whatever.

 > 3. Propoce official user irc channel. There is one in
 > irc.openprojects.net #mplayer. Irc is the fastest way to ask
 > right questions, and help compleate newbie users. A lot of
 > people just stay in their favorite program channel and could
 > answer questions like 'how to add subtitles?', 'can mplayer do that'.

There is an IRC channel, but it is not advertised on the homepage.
Could we add some info there?

 > 3. Make a forum. It is easyer to browse in forum.

Or a newsgroup.  I like the idea, but not so many others do. -users is
too much traffic for me to follow on a constant basis, I would prefer
to have it in a newsgroup.

 > 4. All repeating question from the forum should go in the FAQ.

You can help with that.  Please read DOCS/tech/patches.txt and start
collecting those FAQs.

 > 5. FAQ, forum ,channel and Documentation links should be visible at
 > first look in the web homepage.

IRC channel could be advertised on the homepage, yes.

 > 8. It is not bad to include a short video clip to test does mplayer work
 > at all.

Not include.  Maybe put a few links in the download section for easy
testing.

 > 11. Make compleat release package with mplayer, all (L)GPL codecses, 
 > win32.dll, skins, etc...

I agree.  A one size fits all package that contains a font and the
default gui would probably help a lot.  This way people can choose if
they want to download individual components or just one big tarball
that will suffice in 80% of the cases.

 > 12. Automated Bugreport. Something like ./mkbugreport test.avi

Has been proposed and started.  It's not that easy however.

 > On developer side:
 > 1. There must have some way to track the bugs. Some bugs are
 > daleied and then forgoten.

Something like bugzilla would be nice.  But it might be overkill for
mplayer.  Maybe we can have a wishlist file in addition to the TODO
that collects all the most frequent enhancement requests from -users.
No guarantee for implementation of course :-), but this may reduce
questions.  Both should have a prominent place on the webpage.

 > 2. Maybe speacial mailist for reporting changes in behavior. e.g
 > When a developer add new function (s)he must send a short notice
 > about the change and how it works now. This will be easyer for 
 > none English (hungarian) doc writers, to read that list instead of cvs.

Sounds nice, but I doubt you will get much support for this idea.

 > Finaly. If mplayer projects need more documentation writes
 > then add an advertisement in the mphq homepage. Resently I sow a
 > xmms developer looking for apartment:O

Definitely.  There is no "Getting involved" section whatsoever.  I
believe a little note like 

  We always need good coders and docs writers.
  If you want to get involved, read all of DOCS/ and DOCS/tech/, have
  a look at (list of useful links) and start coding.  Why don't you
  try tackling one of the items from the TODO or WISHLIST?  Help is
  available on -mplayer-dev-eng or #mplayerdev.

might do wonders.  There is no clear way to get involved at the
moment.  Nilmoni Deb for example posted an offer to help on -dev-eng a
while back and never got answered.  I replied in private and sort of
recruited him and I am hardly a developer.  And now he is contributing
docs, code and quality bug reports...

I've been having similar ideas for some time, now somebody else spoke
up.  He has raised some valid points, maybe we can make some of the
suggestions a reality.
Regards

Diego