Re: [talk] why it'd be great to have web interface for submitting simple doc patches

[David Kastrup]

James <address@hidden> writes:

> Says someone who evidently has never built, submitted or tested 'doc'
> patches for LP.

Joseph Wakeling (12):
      Extended documentation on Turkish classical music and Makam.
      Turkish classical music corrections.
      Turkish classical music documentation tweaks.
      Contemporary music: overview of new specialist notation section.
      Contemporary music: pitch and harmony.
      Doc: Sketch of topics for contemporary approaches to rhythm
      Doc: Further Reading for contemporary music.
      Doc: fix duplicate node name.
      COPYING rewrite to clarify licensing.
      COPYING.DOCUMENTATION tweak to mention (lack of) front/back cover texts.
      Doc: CG: Sending and receiving patches via email.
      CG tweak: some extra info on make doc and doc build times

> I think you perception of what we do and why is skewed.
>
>>
>> Yes, you can wait for some other dev team member to pick up your
>> small patch and submit it, but that puts the onus on them to do the
>> work.
>
> So does poorly submitted documentation suggestions, but hey.. *anyone*
> can write documentation right? With clear understanding, good syntax,
> spelling, sentence structure and oh and good lilypond examples.
> Easy-peasy.

Existing documentation beats non-existing documentation.  Our focus
should not be on how to fend off contributions of dubious quality, but
rather on how we can engage contributors in processes that help them
produce good and consistent quality.  Can we find ways to power our
processes more with positive feedback rather than negative feedback?  If
we start with a contributor offering deficient contributions, how do we
arrive at this contributor offering good contributions rather than this
contributor ceasing work on LilyPond?

I am not proposing "accept bad contributions".  How can we make it easy
for someone to improve his work?  I am not sure that the answers for
documentation are necessarily identical to the answers for code.

-- 
David Kastrup