Re: [MC]: better FAQ. was: zip issues, ftp wants, and others

[Pavel Roskin <proski gnu org>]

Hi, Peter!

> > > I downloaded MC for Win from some freeware site, and was not aware
> > > it is part of GNOME and has homepage. 
> >
> > MC is not part of GNOME.  GNOME hosts our mailing lists and CVS
> > repository.  
>
> OK. MC's homepage mentions GNOME and URL is on GNOME. 

Both problems are fixed.  Thank you!  Actually, the reference to GNOME is 
left, but it's much closer to the reality now.

> Don't you think it will be usefull for newcomers here, 
> if email footer has a link to MC homepage and FAQ? And archives?

Some people quote everything, and then the footer is repeated many times.  
Mailman 2.0.x doesn't scan the body, so I cannot add a line saying "you
must remove this line when replying" and enforce this rule by rejecting
offending messages.  Neither can I instruct Mailman to leave only one copy
of this information.

People who want to find the homepage and the FAQ can find them.

> Or for newbies, if first help page has MC URL, too?
> Don't you think it will be usefull for newbie users?

This page is translated into several languages.  I don't want those 
translations to be out of date in the next release.  Besides, what's the 
point?  Why do you think that the newbies need to go to that page?

Actually, the homepage is mentioned in the hints.  I think that the hints
should be gradually removed and replaces with a clear interface and clear,
well organized documentation.

On the other hand, if the homepage changes (as it did while I was writing
this e-mail :-)), do you want to change it in 20 or 50 places, including
documents in the languages you don't understand?  What if those documents
require certain formatting?

In fact, lib/mc.hint.cs doesn't fit 80 columns after replacing
www.gnome.org with www.ibiblio.org, and I cannot do anything to make it
shorter :-(

You just cannot imagine how badly the project is locked with respect to
the documentation just because many contributors preferred to document
defects rather than fix them.

> > > (3) At MC homepage, can we place link to FAQs into more prominent place?
> > I agree, the homepage needs more work.
>
> Just simple reorder: put para3 first (what MC is), screenshots, FAQ
> and HOW-TOs first (for newbies). Then, technical stuff for gurus.
> Use [H2] FAQ [/H2] to make FAQ more visible. Not much of work, IMHO.

H2 meant for headers of sections of the second level.  I'm not using any
sections.  Besides, the homepage is a table - what sections can be in a
table?

I have moved FAQ before development tools, but if you want it to be more
visible, the page should be redesigned.  And most importantly - the FAQ
should be updated first to be useful.

> OK. I propose to create new FAQ and keep also link to old one.

That's exactly the problem.  I cannot expect users to read the new FAQ,
the old FAQ, the manual, the help file, the hint file, the homepage,
INSTALL, INSTALL.FAST and INSTALL.xxx for their OS.

If you want to help, write a new FAQ that can replace, not supplement, the
old FAQ.

> I just volunteered to be doc maintainer. Did you notice? ;-)

Yes.  Please start with something small so that you don't risk too much.  

> If developers are swamped, somebody else might help with docs. That's me.

Let's see.  There is not so much development going on.  We are approaching 
the release, so it's mostly bug fixing and work on the documentation.

> My idea is, I can write first draft of docs, and then gurus can fix
> misunderstandings. Obviously, gurus cannot ask stupid questions.

... but they are asked stupid questions all the time, so they know which 
of them are frequent.

> We need beginners for that... ;-)

Not sure.  Beginners often resort to cheap hacks (see H2 above) and don't
see the project as a whole.  But let's try anyway.

> > > (6) About forgetting F-keys:
> > >
> > > This bug bite me, too, before I realized what is going on. Bad news,
> > > this bug will bite a novice when just experimenting with MC - and might
> > > scare her away from MC forever.
> >
> > Also in TODO.
>
> How do you plan to handle that?

I'm planning to add backup functionality to the profile code, so that the
backups are used always.

> This bug desperately needs to go into FAQs or HOW-TOs. 
> Again: I can do that....

I don't think this question is asked very often.  I don't like documenting 
bugs as an alternative to fixing them.

> Maybe you can decide, which fixes are "critical", and rest can wait
> until next release.

Did you see src/TODO at all?  It's sorted already, and profile backup is 
planned for version 4.6.1.

> > We have one single "Auto save setup" option.  Splitting it means remaking 
> > the dialog and changing the documentation.
>
> What about if I'll do docs, you'll do dialog? ;-)

I want to get 4.6.0 released.  There are enough new features already.  
The translations are mostly frozen, unless the new string is an
alternative to "core dumped" (as it was with "Macro recursion is too
deep").

> Yeah, now I recall. Exactly as in NC... ;-)

I don't know what you mean.  If you mean my conservatism about new
dialogs, there are reasons for that.  Users have hard time finding "Learn
keys" even now.

Recommended reading: http://iarchitect.com/
In particular, looks at this: http://iarchitect.com/tabs.htm#TAB25

> I disabled Autosave and it works better (for what I want) now.

I wish I could disable it by default, but I don't think it's the right
thing to do until all defaults can be written explicitly to mc.lib for
reference.

-- 
Regards,
Pavel Roskin