Re: problems with learning lilypond

[Carl D. Sorensen]

On 11/27/08 2:13 AM, "John Sellers" <address@hidden> wrote:
> 
> I hear your pain.  I'll do what I can, but it may not be much.  I'm currently
> taking violin lessons from Jeremy Cohen (Grammy nominated this year), and
> Julian Smedley (Berkeley Hot Club and others), and Guitar from Jimmy Luttrell
> (Entered the Western Swing Hall of Fame this year.)

John, I'm going to try say this gently, so as not to cause hard feelings.
If I do things wrong, please consider that I'm not trying to be offensive.

I'm always happy to hear a bit about the musical lives of people using
LilyPond, but your first paragraph sounds a bit like name dropping with the
intent of establishing you as an expert, perhaps superior to the rest of us
peons.  I'll give you the benefit of the doubt, and believe that you didn't
intend that, so just consider this a bit of feedback about a perhaps
unintended effect of your writing style.

> 
> So, needless to say, I am working very hard and am very busy.

There's a potential implication that none of the rest of us are working very
hard or are very busy.  Again, I'll give you the benefit of the doubt.  If
we can keep from getting sidetracked by this type of issue, it'll be much
more helpful for moving LilyPond forward.

> 
> But I do have some ideas, and maybe we could have an on going dialog at such a
> pace that would not be too much of a burden to either you or me.

I'm fine to have an ongoing dialog.  And we'd love to have suggestions about
improving LilyPond.  The more specific, the better.

> 
> My first thought out of the box?  Would be to start working on a low-overhead
> system for capturing and redirecting stuck and frustrated users at the point
> they get stuck or frustrated.  Feedback systems are often too high overhead to
> your side or the user side to be really effective.  Most attempts to create
> such a system are also not so easy to do right because it is really hard to
> get both sides of the picture without too much effort, and if the effort isn't
> spent, then you end up with something less than successful.
> 
> But for starters a carefully constructed "first contact" in-context link might
> be a first step on this path.  You want to get the feed back without pigeon
> holing the user and at the same time, not overburdening one's organization
> with umpteen Jillion "feedbacks".  One way might be that the feed back box is
> fronted with a carefully constructed explanation about your resource
> limitations, asking the user to go the extra mile to boil down and re-boil
> down their feedback to make it clear and precise about their problem.  One way
> to do this would be to use something like the Google Idea Contest template,
> but boiling it down to the specific purpose of getting unsticking/frustration
> fixing feeback, carefully structuring and limiting the form to a certain size
> while explaining to the user exactly why they need to be clear and precise.
> Googles form is wonderful  guide to structuring ideas in a constructive
> form...this same concept could be adapted to your purposes.  What Google's
> feedback form lacked was immediate feedback on "size limitation" as the person
> typed...in other words it wasn't until the person filled out the whole form
> and discovered their text was too wordy. (just like I am now...lazy me...see
> you don't want this...you should limit my comments to a clear title, a short
> explanation of my idea,  a larger  description...etc....see the Google form if
> you can find it.  Google's form would have been perfect if they had had an
> automatic character counter on each field to tell the user when the limit was
> reached....and perhaps explained even more (in context) why clarity was
> needed.

I like the fact that you got to a specific idea of using the Google Idea
Contest template.  Unfortunately, the Google Idea Contest template appears
to have been taken down with the end of the submission period, so I can't
use it to help us.

Until we have somebody whose itch is to have a web-based, form-driven
feedback system, we're going to just have to live with email based systems.
I have proposed a Getting Help webpage as part of the LilyPond website (it's
on the -devel list, but hasn't yet posted to the archives.  When it does
post, you can find it at
<http://lists.gnu.org/archive/html/lilypond-devel/2008-11/threads.html>).
The page would have a link to a good resource on forming a clear question to
ask from mailing lists.
> 
> If you were to do this in a way that can be clearly understood, I think you
> will be surprised how much work people are willing to put into making their
> explanation of their problem clear for you.

No, I'm not surprised.  Most of the requests on -user are clear and concise.
The primary exception to this rule is the requests from brand-new users, who
need some help getting started.  That's why Trevor wrote the new Learning
Manual.

> 
> Taking this feedback form, if it is structured right, would enable the
> lilypond employee/expert/helper quickly recognize exactly what kind of
> remediation is needed.  I would expect this remediation be simply a link other
> already written documentation.
> 

This is our primary form of help provided on -user.  With the new improved
manual, nearly every response (especially to a "typical" question) is of the
form "Here's a summary of how to do it.  See the manual section XYZ for more
information."


> Step two, after some experience with this kind of feed back, would likely lead
> to the "I'm frustrated/stuck" link being replaced with a SPECIFIC SHORT LIST
> of ramediation which completely covers the knowledge presented.

There is a start of this, at the LilyPond wiki.  I've proposed a link to
that wiki for the Getting Help page.  You can find this at
<http://lilypondwiki.tuxfamily.org/index.php?title=Main_Page>.

> 
> Step three, after a lot of experience with this kind of feed back....taking
> from the very outset to plan a systematic way of presenting the kind of
> topological sort of dependencies and compiler and all that other fancy
> stuff....down the road....we put together a world class back end to your
> documentation which was able to ramediate anything and everything that is
> compiled....

I'm sorry, but I have no idea what you mean by "topological sort of
dependencies and compiler", but I'm willing to wait for "down the road" to
come later.

> oh yea...minor detail...if and when you every reach that stage, it
> means putting in place an infrastructure for the programmers to enable them to
> do the programming and the documentation of the logic of that programming at
> the same time so there is a one to one correspondence to what liliypond
> compiler does and the documentation which describes that particular part of
> the language does.  Just as the compiler has to know what the language means
> in order to turn it into music, the user has to know that same thing in order
> to know what to type in order to turn it into music. See the parallel???

Yes, I see the parallel.  But asking the programmers to "document the logic"
of the source code in some other language than the programming language
itself is a recipe for disaster.  The English language will have different
meanings than the programming language.  Getting the two to exactly match
will be almost impossible.  Keeping the two synchronized *will* be
impossible.  

AFAICS, you have made a request here for Literate Programming
<http://www.literateprogramming.com/>.  As far as I know, there is no
Literate Programming framework involving Guile.  If there were, and if we
had somebody who was interested enough in Literate Programming to do it, I
think it would be great to get Literate Programming implemented for
LilyPond.  But given the scarce resources we have available, I'd much rather
have development time spent on improving the functionality (e.g. fixing the
part combiner) instead of redoing the core in Literate Programming style.

>  But 
> that is way down the road, first you have to understand from experience how
> the user's needs work, and you aren't going to get that except from the
> feedback...thus starting with the "frustration/stuck" links.  Eventually
> understanding how users get stuck and frustrated looking at a particular piece
> of code will tell you how to use the compiler parser for that particular piece
> of code to automate feeding them back to the documentation to get them
> unstuck, and in fact, what kind of documentation is needed to get them
> unstuck...a long row to hoe....but just think...a chance to be the best in the
> world.

When you use the word "code" here, do you mean LilyPond code, or source
code?

> 
> End of another tirade....so....are you stuck or frustrated? shoot...I'm game
> for a long-term constructive dialog....but keep to the point of going forward
> with this...if you are game.
> 

I'm game for a long-term constructive relationship, more than a long-term
constructive dialogue.  Dialogue is just talking.  I'd be happier to see
something other than talk happening.  If you're really interested in moving
this way, I'd like to see some kind of a specific mock-up or description of
some code to move forward.

I hope you won't take offense, but I'm really not interested in being your
free employee.  I'm more interested in being your colleague or collaborator.
I might (depending on the time requirements and the potential benefit) be
willing to work on your proposed system with you.  I'm certainly not
interested on working on it *for* you.

LilyPond is *not* a project where things get done by somebody coming in and
saying "I think you should do this."  It *is* a project where lots of good
stuff happens by people coming in and saying "I think we need this, and I've
started something here.  Can I get some help".  With this second attitude,
LilyPond has shown a remarkable ability to include lots of people, even me.

Thanks,

Carl