incubator-ooo-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 Tue, 02 Aug 2011 17:18:37 GMT
On Tue, Aug 2, 2011 at 12:54 PM, Dennis E. Hamilton
<dennis.hamilton@acm.org> wrote:
> I'm not sure we are all talking about the same documentation.  I suppose the OOODEV
wiki is the appropriate place to be doing that documentation, whatever it is, that is intended
in the guidelines.
>

I'm thinking of these things that are necessary for anyone to make use
of the product. The core documentation.  A look around other Apache
projects would give some idea of what that doc is, at least from a
developer's perspective.  But there is analogous doc requirements for
users, admins and app developers.  Honestly, I think most of what we
call doc is "core doc".

> When we see the equivalent on OpenOffice.org, we should, on a per-case basis, redirect
it to OOODEV perhaps.
>

I don't think we want to move content across different wiki
applications.  I'd be happy to delete OOODEV and stick with MediaWiki
for both wikis.  That would give us some consistency in look and feel.
 It would also allow the public wiki to be a sandbox or lab where
anyone could propose and develop new doc sets.  As the doc matured, it
could then me integrated into the official doc and maintained from
there.  If we have a consistent license and markup, we can do things
like that.


> But we do need to get to specific cases and handle them individually.
>

Agreed.  We'll learn by doing as well.

> For a general-public editable wiki, I think sticking with the Creative Commons Attribution
license should be just fine where it is already supplied.  More people seem to know what
that is, and it is fully permissive without what appears to be such high ceremony as the ALv2.
>

I disagree.  Let me explain why.  The wiki currently holds a lot of
detailed plans and designs for future features.  So it is used for
project planning and technical design.  See, for example:

http://wiki.services.openoffice.org/wiki/Calc/Features/Multi-range_copy_and_paste

There are also pages with more detailed designs, including embedded source code:

http://wiki.services.openoffice.org/wiki/Calc/Implementation/Spreadsheet_Functions#formula.2Finc.2Fformula.2Fcompiler.hrc

So it is very possible that patentable methods and copyrighted source
code could migrate directly from the wiki into project source code.
It is prudent to ensure that those who contribute to these wiki pages
are making the necessary assertions with regards to any IP involved.
This is no different than the agreements you and I made when deciding
to work on standards at OASIS.  Even though it is just "documentation"
that documentation is the blueprint for software, and as such has IP
implications.

Of course, the alternate way is to move these pages and those like it
into a project-wiki which is only writable by those who have returned
the iCLA.

> And we should look around at some of the TLP project wikis that allow public contributions.
>

Pass along some links if you find some good examples.


-Rob


>  - Dennis
>
> -----Original Message-----
> From: Rob Weir [mailto:apache@robweir.com]
> Sent: Tuesday, August 02, 2011 09:28
> To: ooo-dev@incubator.apache.org
> Subject: Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org
branding)
>
> On Tue, Aug 2, 2011 at 12:10 PM, Andy Brown <andy@the-martin-byrd.net> wrote:
>> Rob Weir wrote:
>>
>>> At Apache, every committer has the ability to veto a change.  Not just
>>> me.  Far from it.
>>
>> True.
>>
>>> In any case, in order to move the argument forward, I'd like to
>>> reiterate thecific concerns that I have, to which I've seen no
>>> response other than "we don't want to change".  But no one is
>>> addressing the fundamental questions:
>>>
>>> 1) How do we ensure that the future documentation is under the Apache
>>> 2.0 license so that it can be copied, modified and redistributed
>>> freely by others?
>>
>> If you talking the wiki, instead of requiring an ICLA as a person has to
>> create an account, why not make it part of that process that "All submitted
>> contributions are under AL2 license".  Would that not be sufficient?
>>
>
> The IPMC guidance, via the Podling Guide that they have published [1] is:
>
> "Podlings may use a wiki to create documentation (including the
> website) providing that follow the guidelines. In particular, care
> must be taken to ensure that access to the wiki used to create
> documentation is restricted to only those with filed CLAs. The PPMC
> MUST review all changes and ensure that trust is not abused."
>
> I personally like your idea of having a click-through-license grant on
> the wiki itself, either as part of account creation or on the edit
> page itself.  But if we did that, I'd suggest some related issues to
> address:
>
> 1) We shouldn't just ignore IPMC guidance.  There may be some
> allowance for variation in procedures, but that should not be assumed.
>  If we want to do something differently, then we need to write up that
> proposal, get consensus here among PPMC members, and then take it to
> the IPMC and probably Apache Legal Affairs (to review whatever
> language we use).  I'd gladly support that.
>
> 2) We need a credible security mechanism for the wiki.  Today, for
> example, it is not required for a user to give their real name (the
> field is optional).  And the password can be as little as 1 character.
>  (Yup, I just created an account with password="x").  With 15,000
> zombie accounts, lack of real names and the ability for users to
> create trivially crackable accounts, it would be hard to really
> identify a change to a particular person.
>
> [1] http://incubator.apache.org/guides/sites.html
>
>>> 2) How do we ensure that the documentation is under PPMC oversight and
>>> remains high quality?
>>
>> I received a daily report of all changes to the wiki, there is also the
>> option for "as done" report.  It would only take a few minutes to do a quick
>> review of those changes, an revert them if needed.
>>
>
> OK.  Maybe that report could be directed to the ooo-commits list as well?
>
>>> I'm open to discussions of various technical and procedural means to
>>> achieve these goals.  But I am adamant in achieving them one way or
>>> another.
>>
>> Would the above listed work?
>>
>
> I think that takes us in the right direction.  Thanks.
>
>> Andy
>>
>
>

Mime
View raw message