Hi Rob, Hi all, 2012/12/1 Rob Weir <robw...@apache.org>
> On Sat, Dec 1, 2012 at 7:55 AM, Guy Waterval <waterval....@gmail.com> > wrote: > > Hi Rob, > > Hi all, > > > > 2012/11/30 Rob Weir <robw...@apache.org> > > > > [...] > > > >> > >> That would be the point of a call for volunteers then, wouldn't it? > >> Bring in more volunteers with the skills needed to create an outline, > >> etc. There are independent books written on OpenOffice and certainly > >> Microsoft Office all the time. There are many people who have the > >> skills needed. All we need to do is ask. > >> > >> The goal should be (IMHO) to reach a critical mass of volunteers where > >> the tasks are not only doable, but fun. > >> > > > > My personal opinion is that the way proposed by Ricardo, with an Apache > > license, is actually the more innovative and realistic we have for an > > online documentation at this time. His approach has the merit of > suggesting > > a sustainable solution for the project and which can grow with it. So, > the > > reflexion should be more oriented in finding a way to help him to develop > > his game, if desired.. > > The nature of things will lead to either: > > 1) We define the documentation plan, at least to the level of a list > of deliverables, a new d...@openoffice.apache.org mailing list, a > workflow, a technological approach (what formats and templates, etc.) > and a means of tracking status (page on the wiki) and *then* do a call > for volunteers. If we do this then new volunteers will naturally > adapt to the workflow and process that already is in-progress, > I think that a d...@openoffice.apache.org mailing list and the acceptation of the Alv2.0 for the docs are absolutely necessary. #1 has my preference. It's not obligatory a totally fixed approach but it allows to create a basis and to begin something. We have already something on the table and Ricardo and collegues are competent, certainly opened and motivated. Why not to try the way they have began. Nobody is excluded. It allows to regroup all people who are interested in an apache documentation project and avoids to discourage others, who are investing their time and energy aside the group, to find finally a home where they could really get support and express their qualities. Why not to build a winning team with the people here in the group? > > or > > 2) We do a call for volunteers with nothing more than a new > d...@openoffice.apache.org mailing list, and hash out the details on > that list with the new volunteers. > > So if someone has strong views on how things should be done, then they > really need to step up and define #1. Otherwise, a recruitment > activity will lead to a larger group of documentation volunteers who > will have a mind of their own and could take this in other directions. > This isn't necessarily a bad thing, of course. > #2 is a little the "big bang" method. Difficult to make a choice in this case, only suggestions (probably one approach pro player), nothing concrete on the table. The risk is to stay blocked as it was the case up to now. > > Another consideration: It is easier to find (and engage with) > volunteers who step into an ongoing activity like #1. But it is > easier to attract an alpha "documentation architect" if things are not > already defined. > It's the loto game. You have to find a Zorro who accepts to work as volunteer (and freely). I don't think that you would have more chance with #2, which represents a big charge. Moreover, giving priority to this method could perhaps demotivate some members in this group. > > Of course, these are not hard rules, but are considerations and > tendencies. There are no right answers. With QA we did a call for > volunteers that was more like #1. With marketing it is more like #2. > Translation is in the middle, with an existing workflow, but one that > is being improved by new volunteers, > > In any case, I think that a new doc mailing list will be essential for > any approach, since new doc volunteers would be deterred by the > traffic on the dev list. > A new doc mailing list is absolutely necessary. It could offer an alternative to the odf authors solution, as this group is the documentation area of LibreOffice. Even if people are totally correct there, we have to be realistic, the conditions are not good there for people working on an apache documentation project. A+ -- gw > >
