On Aug 2, 2011, at 7:32 AM, Dennis E. Hamilton 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. > > There are cross-over cases, such as authoring of what will be embedded help > (in many languages) and also the support for on-line help. But even for > on-line help it would be great if it could be community-augmented. > > All we're accomplishing here is guaranteeing that the only well-written > documents and congenial forums for users will carry the LibreOffice logo. > > We already have two separate wikis, one that the community uses and one that > requires committers to make the changes. I notice the second one is not > getting much activity. > > I think this stance is too heavy-handed in an area where there is no > demonstration of harm and a great need for community engagement. We need to > be flexible here, and quickly too.
+1 - Let's listen carefully. We don't have to have all the answers immediately and we don't need to drown in slew of emails. Regards, Dave > > - Dennis > > -----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 >> >> >> >> >> >> >
