openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <apa...@robweir.com>
Subject Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)
Date Wed, 03 Aug 2011 00:43:58 GMT
On Tue, Aug 2, 2011 at 8:32 PM, Jean Hollis Weber <jeanweber@gmail.com> 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
>> <dennis.hamilton@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.
>

>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:apache@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 <jeanweber@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
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>
>
>
>

Mime
View raw message