Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of acolorado@gmail.com designates
 74.125.82.41 as permitted sender)
MIME-Version: 1.0
Sender: acolorado@gmail.com
In-Reply-To: <4E705A89.2080409@apache.org>
References: <4E705A89.2080409@apache.org>
Date: Wed, 14 Sep 2011 11:25:43 -0500
Message-ID: 
 <CAMK9kTgn66R_S4rWKqRLEdK2TF-hfpy_Y=Pi8xGE9MqMPzqpTg@mail.gmail.com>
Subject: Re: The OOo Community Wiki handover of activities
From: Alexandro Colorado <jza@openoffice.org>
To: ooo-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=0016e64c3972327a7904ace936a6

--0016e64c3972327a7904ace936a6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 14, 2011 at 2:40 AM, Terry Ellison <terrye@apache.org> wrote:

> As has been pointed out by posters on this DL,  I've now "resigned" twice
> from the project.  On the first occasion I said I was leaving but committ=
ed
> to finish off my forum / wiki work first as long as we could avoid a
> ping-pong of personal criticisms / hostile posting on the ooo-dev DL.  Th=
e
> second time I dropped this commitment because it became clear to me that =
we
> were again slipping into personal attacks.  Even so, what I don't want to
> happen is for my decision to leave to cause a "denial of service" because=
 of
> my being a "single point of failure" for some activities.  However, I won=
't
> discuss this thread further on this DL.  I leave this to TJ et al.  I wil=
l
> reply to constructive personal emails, and am happy for any recipients to
> quote that content here.
>
> In the case of the forums, the bulk of the setup work had already been
> completed and so I have been working with Drew Jensen in the background t=
o
> transfer their support and administration to him should the project decid=
e
> to proceed with this migration.  I have pretty much documented these task=
s.
>
> The wiki is a somewhat different issue, because this work wasn't so far
> along, and so I wanted to make some statement on the DL on this.  We have=
 a
> stable build of MW 1.15.5 (albeit not in svn) running on
> ooo-wiki.apache.org with a stale but recent clone of the production wiki
> on it, as the only material content updates have been by a user Hohenheim=
 to
> some of the OOoES NL pages.  I have also activated TJ's account and upgra=
ded
> this to admin / bureaucrat, and I am willing to offer TJ the same occasio=
nal
> support that I am currently providing to Drew whilst he gets up to speed.
>

Also if there is something we could do to support the migration we have a
couple of VPS running with available space and bandwith. Unfortunately at
the moment we still have some todo with the BZ skinning and templates for
the issues.apache.org/ooo site. should this be renamed to
isuess-ooo.apache.org?

Regards.


>
> Whatever the project's long term plans for the wiki, it will remain provi=
de
> a useful reference resource from which to migrate content if the Oracle
> service is shut down.  IIRC, a couple of contributors / committers have
> asked for a copy of the schema and content so that they can work on it an=
d
> on any data migration. So making this available seems to be a sensible wa=
y
> ahead since the vast majority of the content is already publicly accessib=
le
> and could used / scraped under the terms of the PDL, etc.  I will place t=
his
> on the usOOo site.  So please expect to see a file
> http://user.services.openoffice.org/__backup/d27f1bb7c71872c4d2e6eb04d4fc=
6006/READMEposted next at the weekend which will explain how to download th=
is content.
>

I'll dl that to our servers just in case we need extra redundancy.


>
> The issue that I need to be careful about (really on behalf of Oracle / t=
he
> old OOo projects) is that some data elements are not already publicly
> accessible and which could in my view be deemed to be personal data falli=
ng
> under EU Data Protection legislation, so I would need to be a little care=
ful
> about how I expunge these from any copy for developers.  As far as I can =
see
> these could all be mangled to avoid such issues:
>
> *user_password*
> This is already stored in highly mangled (MD5 including salt) format so i=
s
> not readily attacked apart from brute force guessing.  What I will do is =
to
> replace 3 internal letters by 3 pseudo random letters to make such this
> attack more impractical. (see note 1)
>
> *user_real_name
> *This field is not made publicly available, and is only used for content
> attribution.  I will therefore blank this in the dump.  However I will ke=
ep
> a copy and make this accessible to any PPMC member who warrants that this
> will be used for the purposes of content attribution.
>
> *user_email*
> This field is not publicly available.  I will replace it by
> strcat(md5(user_email), '@dummy.com')  (see note 1)
>
> *watchlist
> *Remove all watchlist entries.  Users can always recreate their own list.
>


How was this part handled for OOo's BZ? My guess is that there was no publi=
c
download so this was never an issue.


>
> *Notes:
> *
> 1. Part of my reason for doing this was a point that Rob made: that Apach=
e
> should require users to explicitly acknowledge some form of ToU as part o=
f
> re-registering to recover any existing account.  I have already started t=
o
> develop a MediaWiki extension form on my VM MW 1.17.0 version which would
> allow any user to "reconnect" to his/her account if either (i) they knew =
the
> existing password, or (ii) knew the existing email address and could issu=
e
> email confirmation from that address.  Any competent PHP/MW developer cou=
ld
> easily do this with the above data element mangling.
>
> 2. I will delete all accounts that have made no contributions to the Main
> or User namespaces.
>
> 3. I am still concerned about this whole issue of content attribution.
>  IIRC, under the old OCA contributors only vested joint rights to Sun/Ora=
cle
> and free licence on any patents.  The base copyright and patents were
> maintained by the originator. The PDL is even tighter of contributor righ=
ts
> retention.  So far we have discarded all audit of contribution in svn and
> are currently considering doing likewise for documentation content, dropp=
ing
> contribution audit trails and defaulting to blanket Apache copyright.  As
> some third parties  might take a different view on this, I propose to kee=
p a
> full private archive of the D/B myself as an independent audit reference.
>
> With these changes, I would be happy to put a copy of the wiki dump on on=
e
> of the old OOo servers so that it could be pulled by any ooo-dev develope=
rs.
>


--=20
*Alexandro Colorado*
*OpenOffice.org* Espa=C3=B1ol
http://es.openoffice.org
fingerprint: E62B CF77 1BEA 0749 C0B8 50B9 3DE6 A84A 68D0 72E6

--0016e64c3972327a7904ace936a6--