-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWoHZWAAoJEKG7hs8nSMR7wVEP/0QT1sJse8Z/aTisqtOr06OA VDWhiW61ch/FOJo8PWXEg57W3Coi/mO6lGkBkUtulBjwfAYpmaMs9jKYuK+WmCjN 94mh5yZAfAHnITwhK482K5KASCWZ0AsngSekcdIMtkp6ij/HXTCMYOtaky5+aN0r dDbHHpB7xskjD5mnMHC0mAghWYbAs7SXx0fS/t1xQLZ5H+cKoIpLcnr3orIt729N d6kYomMwUSRqYtCOMkoFsCXGHT68MV9GtV5RIYf+iEewPHJjeHoASRd+kCwnD8kI WYD+ynyWGmC6avDg685OfXhtEW/E7d4f+Kbr4pEZdDdKvGvB27W/jY793lFhJzxK M/mZD604vlAg0OQo2lixY6EXhhqQXF+o5ZTcVck1Pb4pnhGqx/pi2LGMVzWp0shr buMKl11xcc79dLcwkkOcLz3IooLqoUZou7vwR1DWcWj6dyb7RhxOyaP/vwnNZMEl x+7aKc4a6bWZ9NZ1hjTkaWGPtQiYOSlqf6mvbmZNbZcKE3tGo1Md6LpTPpI9MXaZ W3LYFIHu0+Pz9rt6AZMmsR/kROUM2PcB33M7q7LiDw3I5YdwYS2ceps0/uouKF5T QT934jcSTYyj+glt8AP71d9QCFBq8z4Ooc/erCu6ap8XbvLDI9yY+V8FREgE3g22 m/1DlsM3lbOfHdoHDN4y =2pqF -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: doc-unsubscr...@openoffice.apache.org For additional commands, e-mail: doc-h...@openoffice.apache.org
