On Tue, Aug 2, 2011 at 8:32 PM, Jean Hollis Weber <[email protected]> wrote: > On Tue, 2011-08-02 at 10:52 -0400, Rob Weir wrote: >> On Tue, Aug 2, 2011 at 10:32 AM, Dennis E. Hamilton >> <[email protected]> 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. >
>From licensing perspective it is the same, whether it is content in wikitext or content in attachments to a wiki page. The thing that would be different would be links to content on external sites. If that is not answering your question, maybe you should restate, with a link to a specific example. -Rob > --Jean > >> > >> > -----Original Message----- >> > From: Rob Weir [mailto:[email protected]] >> > Sent: Tuesday, August 02, 2011 05:04 >> > To: [email protected] >> > 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 <[email protected]> >> > 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 >> >> >> >> >> >> >> >> >> >> >> >> >> > >> > > > > >
