On Tue, Jan 8, 2013 at 7:12 AM, RGB ES <rgb.m...@gmail.com> wrote: > 2013/1/7 Rob Weir <robw...@apache.org> > >> We have a small set of volunteers right now, but it should be easy to >> attract more if we do a "Call for Volunteers". This worked very well >> for translators, marketing and QA, for example. But what we learned >> there is that you really need to have a project structure in place >> before bringing in new volunteers. Otherwise everyone just sits >> around, waiting for something to happen. >> > > +1 > > > >> >> So this suggests the following steps: >> >> 1) Establish a basic list of deliverables for the AOO 4.0 time frame. >> Realistically, what should we aim for in the April/May time frame? >> Maybe think of this as a minimal goal, plus some "stretch goals" that >> we might be able to do if we have more volunteers. >> > > I think we should aim for an online documentation on the wiki, with the > "basics" and maybe some "cheat sheets" for each component. Content is more > important than format and the wiki is the easiest way to involve more > people and get content ready in a short time. >
I'm fine with using the wiki as an authoring environment. It even has some advantages as final format: 1) It is a webpage, so it is indexed by Google and easily findable 2) As a wiki it encourages user contributions and improvements 3) It allows us to make the documentation be a "living document". The downside is there is more work to get the content into an PDF, ebook or printer book format. But not impossible. We just need to find or develop the right tool chain. But since we're using the MWiki we'll probably find out that someone has already solved this problem for us. > > >> >> >> 2) Do some basic preparatory work for at least some of the deliverables, >> say: >> >> a) design the document templates >> > > If we point to the wiki, templates for "real books" can be done later, but > there are other things we needs to agree on: for example, screenshots. If > every author take screenshots on their system we will end with a > very heterogeneous collection of OSs and desktop themes, giving a > very unprofessional look. In fact, if I read it right, using screen shots > taken on windows could not be completely "legal": > Right. Even if we use the wiki there are still some conventions we'll want to adopt, even if they are not in the form of "templates". What do we need to agree on to ensure a common look & feel? Also, agreement on editorial conventions, e.g., do we refer to the user directly in the second person, or only as third person? Also, do we want to make individual, standalone guides on the wiki? Or do we want to hyperlink them into a larger whole, an "Encyclopedia OpenOffice"? We have the ability, if we chose, to avoid the kind of tradeoffs that accompany traditional documentation, where you are either good for beginners, or are detailed. Task-oriented or reference? We can be both at the same time, with hypertext and the right structure. > > http://www.microsoft.com/About/Legal/EN/US/IntellectualProperty/Permissions/Default.aspx#ERG > > "4. Do not use screen shots that contain third-party content." > > This and number 2 "Do not use portions of screen shots" are problematic. I > don't think they will ever make problems for this, but... > I think this means, don't use portions of a screenshot where the screenshot is of a Microsoft copyrighted image. So don't use portion of Excel or Word screenshot. But we can use a portion of our own UI. > > >> >> b) define a table of contents or rough content outline for each core >> deliverable >> > > We can start from this draft > > https://cwiki.apache.org/confluence/display/OOOUSERS/Details+on+Scenario+3#DetailsonScenario3-ProposedTOC > > maybe focusing on the first two chapters for now. > I'll take a look. Thanks for putting that together. -Rob > > >> >> c) agree on what the workflow will look like: authoring, editing, >> public review, translation, publication, etc. We don't need 100% >> detail, but we need enough to have a meaningful agreement among >> ourselves what the process should look like. >> >> >> 3) Call for Volunteers -- By this point we've defined enough of a >> framework that we can bring in new volunteers without it being too >> chaotic. >> >> >> 4) Execute >> >> >> 5) Deliver >> >> >> Does this make sense? >> > > Perfect sense! Thanks for starting this discussion. > > Regards > Ricardo > > > >> >> -Rob >>
