On Tue, 2011-08-02 at 10:52 -0400, Rob Weir wrote: > On Tue, Aug 2, 2011 at 10:32 AM, Dennis E. Hamilton > <dennis.hamil...@acm.org> wrote: > > -1 > > > > I don't understand why there is continued pressing that things not in a > > release have to be treated as if it requires the same treatment as the > > content of a release. I thought we had worked a high-level sketch of the > > user documentation case with Jean Hollis Weber some time ago on this list. > > > > That was something else entirely, ODFAuthors.org, a site that is > external to Apache. We're not discussing that right now. What we're > discussing is the content at wiki.services.openoffice.org, which we > are planning to be part of the Apache OpenOffice project. Two > different things.
*I* was talking about the docs produced by ODFAuthors, in my note quoted below, and I asked a question that was not answered; the answer was about the material directly edited on the wiki, not about the material I asked about. --Jean > > > > -----Original Message----- > > From: Rob Weir [mailto:apa...@robweir.com] > > Sent: Tuesday, August 02, 2011 05:04 > > To: ooo-dev@incubator.apache.org > > Subject: Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was > > re:OpenOffice.org branding) > > > > On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber <jeanwe...@gmail.com> > > wrote: > >> On Mon, 2011-08-01 at 21:24 -0400, Rob Weir wrote: > >>> I'd look at it like this: The documentation that is needed for our > >>> users to be successful with our product, from end users, to admins, to > >>> application developers, that documentation is product documentation. > >>> If having it deleted or defaced, without us noticing it, would cause > >>> our users some harm, then it is product documentation. If the right > >>> to copy, modify and redistribute the documentation is essentially to > >>> successful creating and hosting a new port or translation, or even a > >>> commercial derivative or an open source fork, of the project, then it > >>> is product documentation. > >> > >> Leaving aside for the moment all the other user-doc type items on the > >> wiki, and looking specifically at the existing current set of user > >> guides (which are in ODT/PDF format, but made available for download > >> from the existing OOo wiki), I'm unclear how they will fit into this. > >> They are not currently under the Apache license, and we would never be > >> able to track down all the contributors to get them to agree to the > >> license and/or sign the iCLA. So are we talking only about future > >> updates to these docs? And if so, do you mean that every future > >> contributor to these guides during their production must sign the iCLA? > >> Or just that only someone with suitable access rights (committer?) can > >> put them on the wiki (in ODT/PDF format)? Or something else? > >> > > > > I'd like us to treat documentation like we do code. Not necessarily > > the same tools, but the same care for provenance, accountability and > > quality, namely: > > > > 1) We welcome "patches" and "contributions" from anyone, but these > > must be first reviewed and approved by a project committer before they > > become part of the documentation set. Any such contributions must be > > made under Apache 2.0 license. > > > > 2) Only project committers have direct write access to the > > documentation. This requires that they first sign the iCLA. > > > > 3) All contributions, whether from the public or from committers and > > tracked/logged, so we can accurately determine who made a given > > change. So no anonymous or pseudonymous patches. A user id that we > > can trace to a real email address is fine. > > > > With code this works by non-committer contributors sending patches > > (diffs) to the mailing list, where they are merged in and reviewed by > > a committer, and then checked into the repository. With > > documentation, using a wiki , we would need a different mechanism for > > achieving this. Luckily there are MediaWiki extensions to enable > > this. > > > > I'd like to preserve the immediate nature of editing on the wiki. > > That is its strength. But we need to find away to also get this under > > project oversight as well. I think we can do both, without too much > > annoyance to contributors. > > > >> --Jean > >> > >> > >> > >> > >> > >> > > > >
