Thanks Marc, I've already market that mail for analyse. I'll write a comment later night.
Cheers 2010/11/3 Marc Paré <[email protected]> > Le 2010-11-03 08:00, Carlos Jenkins a écrit : > > Hi! >> >> 2010/11/3 Benjamin Horst<[email protected]> >> >> On Nov 3, 2010, at 6:59 AM, Carlos Jenkins wrote: >>> This list looks very good! >>> >>> Thanks! :D >> >> >> I suppose we're looking at Drupal 6 for the site, but is there a chance >>> Drupal 7 and updated modules will be ready in time for us to use it from >>> the >>> beginning? >>> >>> Not sure, it's a possibility we need to analyse. If chosen, Drupal 7 >> will >> help us to prolong the life frame of the website framework. I'm actually >> worried that when Drupal 7 comes out, all modules we need doesn't have a >> version for Drupal 7/not equivalent modules are avalaible, and that those >> module where not tested enough as they are just been started to get used >> in >> production sites (as the release of Drupal 7). I suppose Drupal 7 will >> come >> with a migration plan and facilities for people using Drupal 6. My >> proposal, >> for now, would be to build things in Drupal 6, then, when Drupal 7 is >> released, wait a prudence time to allow modules to get migrated and >> improved >> and tested, and then, make a migration plan and execute it. Where are >> talking about 1 and a half or 2 years maybe. >> >> My two cents. >> >> Cheers >> >> > Hi Carlos, you may want to check out another long response from Jean Hollis > Weber in the documentation mailist. Here it is: > > ================== > > On Tue, 2010-11-02 at 20:56 -0400, Marc Paré wrote: > > > Hi Jean > > > > > > Thanks for your answers and all of the other documentation team > answers. > > > This is really a lot of good information. If only there were enough > > > members to do all that we wanted. Let's hope that with LibO more people > > > will come on-board for help with the documentation team. I am guessing > > > the the US and Canadian have not really been tapped and I am also > > > guessing the Mexico is probably the same. Once we organise and market > we > > > will hopefully get more people on board. > We actually have a lot of volunteers at OOoAuthors, but only 10 or so of > them do much of anything. Most of that 10 do excellent work (mainly > editing and reviewing, but also some writing) but they are not available > as much as is needed. > > > > Could you tell me (I am also a the LibO Marketing Team member) how many > > > more members you would need at this point, what type of qualifications > > > they should have? Ideally, how many would the documentation team need? > Ideally, for the user guides we need 5 coordinator/ editor/ publishers > (I don't really know what to call them) -- 1 for each book -- and I > don't know how many doing the writing/ editing/ reviewing/ indexing/ > graphics. I would like to see each chapter have someone taking > responsibility for keeping it up to date, though obviously one person > could take on several chapters, either in one book or a series of > related chapters in several books: for example, all the chapters on > customizing or all the chapters on printing & PDF creation. That would > maximize consistency with the least effort. So... maybe 20 people? (And > I'm not considering other types of docs, such as FAQs, tutorials, > how-tos, etc.) > > This page has more info than you want, but one relevant part is the list > of things we do when publishing a chapter or a book. There is a lot of > post-processing related to where the files are put, wikifying them, etc. > Even if much of this can be (semi-)automated, someone has to start the > process and verify that it has completed correctly. > > http://wiki.services.openoffice.org/wiki/Documentation/Dashboard/Producing_User_Guides > > I don't care about qualifications as such, but volunteers really need > some basic skills that are often lacking but can be highly developed in > people with no formal quals. > > <aside> > Most volunteers say they will "proofread" but what we need most is > people to do research, write, and critically review/test what others > have written. Cleaning up the English when the facts are wrong isn't > much help. > > Much of the work requires good analytical & problem-solving skills or > else it's done too superficially and misses too many errors, omissions, > and important inconsistencies (such as, does the figure actually show > what the text says it shows? If not, which is wrong? Are the > instructions complete, correct, and written at an appropriate level for > the audience?), not nitpicking over fine points of grammar or word > choice. > > Technical writing/ editing/ indexing/ graphics experience can be > valuable but IMO is not necessary. Also, many people with weak skills in > English make excellent reviewers/testers and often good writers (though > they need to be teamed with an editor) -- because they can do research, > organize the material, check facts, etc. > </aside> > > > > > > > Also do you know if the developer docs have a workflow page and could > > > you point me to this page? > I don't know, sorry. Someone who has worked in that area might know. > Clayton (the other OOo Docs Co-Lead and an Oracle employee) oversees > that area. I do know the developer docs are wiki-based and are edited by > a variety of people. I have no idea how much updating is needed. > > Oh, and there is the Installation Guide, which has sort of been taken > over by OOoAuthors so should probably be considered as another "user > guide" needing someone to be responsible for it. > > ================== > > Cheers > > Marc > > > > -- > E-mail to [email protected] <website%[email protected]>for > instructions on how to unsubscribe > List archives are available at http://www.libreoffice.org/lists/website/ > All messages you send to this list will be publicly archived and cannot be > deleted > > -- http://www.cjenkins.net/ http://csl-tec.softwarelibrecr.org/ -- E-mail to [email protected] for instructions on how to unsubscribe List archives are available at http://www.libreoffice.org/lists/website/ All messages you send to this list will be publicly archived and cannot be deleted
