toki wrote:
> On 20/01/2016 23:02, Dennis E. Hamilton wrote:
> 
>> I think that having a structure for contributors finding work and also
>  finding any guidance they need is a great idea.
> 
> One individual whose sole function is to say: "Do this", and then
> follows up weekly, to see how "this" is progressing, and sending help
> that way, when needed.
> 
> "Do this" can be writing, copy-editing, proofreading, translating, line
> editing, or maybe even plot editing the document.
> 
> "The document" can be an entire manual, a chapter, a sub-chapter, how-to
> for something that ends up on the wiki, dead tree printed, and PDF.  In
> future, that might expand to include the Presentation format, video, and
> audio version.
> 
> When somebody sends an email saying "I'd like to help with the
> documentation project". The first response is: "Which of the follow
> skills do you have? Line editing, copy editing, blah, blah, blah." The
> second response is: "Here is x document, go do blah", where blah is a
> skill that the individual claimed.
> 
> If the new-volunteer claims no skills, then they are given a list of
> books to study, so that they can learn the appropriate skills. If need
> be, they are also given tests, to demonstrate how well they know the
> appropriate skill.
> 
> No sending people to a wiki page to read, and decide what they would
> like to do for the documentation project.
> No waiting for people to ask for help in doing something.
> 
>> We need a way for that to be self-organizing without any kind of hiera
> rchy or leadership roles.
> 
> You can either have a team that produces a new user manual every
> quarter, or a team that meanders along, putting out one updated user
> manual every three years.
> 
> The difference is whether each team member is specifically asked to
> write/do something, or if things are left to each individual to step
> forward.
> 
>> That needs to be used in an organic way, with everything operating by
> consensus to the max.
> 
> For some things, you simply have to have one person say "This way, and
> only this way". To do otherwise is to waste way too much time in
> discussing, and maybe voting on otherwise trivial issues. 10th, 11th,
> 12th, 13th, 14th, 15th, 16th, 17th, or 18th edition of Chicago being a
> prime example. I bring Chicago up, precisely because experienced editors
> have their own favourite version, and, unless it made clear up front,
> exactly which version to use, will either use their favourite version,
> or, more commonly, try to persuade everybody to use that version,
> instead of getting on with the task at hand.
> 
>> It may be that there is a bit more-than-usual process structure here f
> or producing documentation on the Wiki and elsewhere.
> 
> The ideal is that the same source document can be used, with minimal
> massaging, in the wiki, the F1 Help file, the dead tree manual, the ePub
> manual, the PDF manual, the video script, the audio script, and where
> ever else documentation needs to be found.
> 
> Right now, that isn't even hypothetically possible. However, if the
> ground work is laid today, in five to seven years, that could be the
> reality.
> 
>> The idea is to build communities that are consensus-focused in their
> operation.
> 
> Writing documentation is not writing FanFic.
> Parleying it into a paying gig is pretty much a non-starter.
> 
>> Formal deliberations must be on the dev@ list, not here on doc@, and
> the binding votes are from the Project Management Committee members,
> 
> How many Project Management Committee members know the difference
> between the 1oth, 11th, 12th, 13th, 14th, 15th, 16th, 17th, and 18th
> edition of Chicago, well enough to be understand why one might not want
> to go with the 19th edition?
> 
> Whilst fundamental to what the final work product looks like, it is
> trivial, in that for publishing houses, which edition to use is the
> first decision made by the senior editor, after they are hired. (This
> applies as much to brand new startups, as it does to the Five Sisters.)
> 
> jonathon
>
Jonathon;

Though I do not necessarily disagree with much of what you said, the
fact remains that if no one steps forward with the necessary skills to
fulfill the role you propose it is not going to happen. As you appear to
have the requisite skills, in the spirit of
the "Apache Way" are you stepping forward to take on that responsibility?

Regards
Keith




Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to