incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lawrence Rosen" <lro...@rosenlaw.com>
Subject RE: Call for comments: Webpage for Listing OpenOffice Consultants
Date Wed, 26 Sep 2012 22:40:46 GMT
The policy implications may be broader than you've summarized below. 

I read the draft disclaimer and I like it. But I'm not convinced that a
disclaimer is sufficient when Apache identifies people or companies who can
help with AOO unless there is also a statement of our right, in our sole
discretion, to remove any listing that does not conform to AOO community
standards (whatever those are?). 

Is there a standard by which you can remove someone from the list?

Is this an opportunity for a job listing board rather than for Apache itself
to manage?

/Larry

Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)
3001 King Ranch Rd., Ukiah, CA 95482
Office: 707-485-1242


-----Original Message-----
From: Donald Whytock [mailto:dwhytock@gmail.com] 
Sent: Wednesday, September 26, 2012 2:04 PM
To: ooo-dev@incubator.apache.org
Subject: Re: Call for comments: Webpage for Listing OpenOffice Consultants

Still suggesting some sort of expiration mechanism (perhaps a timestamp in
the entry, with a scheduled job to prune), so this doesn't become a barnacle
colony.

Don

On Wed, Sep 26, 2012 at 4:58 PM, Rob Weir <robweir@apache.org> wrote:
> Another one of those "larger ecosystem" things I'll be pushing on.
>
> If you recall the legacy OpenOffice.org project had a webpage that 
> listed various consultants who provided services for OpenOffice.  We 
> took it down because it was very out of date and we didn't have time 
> (at that time) to figure out the policy implications and update the 
> content.  Well guess what?  I have time now.
>
> ====> A draft of a proposed approach is on the wiki here:
> https://cwiki.apache.org/confluence/display/OOOUSERS/Draft+--+Apache+O
> penOffice+Consultants+Directory
> <====
>
> I'm working on the XSLT script now.  Looking good so far.
>
> If you read the wiki you'll see the policy implications are minimal:
> We'll be fair and accept all relevant submitted listings, provided
> they don't abuse ASF trademarks,   I don't think we need more than
> that, but adding more is certainly easy enough.
>
> Note also the disclaimer on the wiki, which I'll repeat here.  As a 
> non-profit we need to be careful about how we intersect with 
> commercial activities.  I think this is sufficient, but changes are 
> easy to make.
>
> "Disclaimer:   Although most individual users are able to download and
> use Apache OpenOffice without any help, or with the assistance of 
> volunteers on our Forums and mailing lists, some users, especially 
> corporate users, may have more complex requirements that require 
> commercial services in order to optimize their deployments.  The 
> following individuals and firms offer services that may be of
> interest.   The information provided here was provided by the entities
> named here, and is not verified or endorsed by the Apache OpenOffice 
> project.  We offer these listings as a service to the ecosystem."
>
> If there are no objections to this general approach, I'll proceed as
follows:
>
> 1) Write up a definition of the requirements for the input XML file.
> XML Schema and plain English definition, for use by consultants 
> submitting us listings
>
> 2) Draft a webpage giving info on how consultants can submit a 
> listing.  Would list technical and policy requirements.
>
> 3) Complete XSLT scripts and get them checked in.
>
> 4) Get this all onto the website into a test directory for review.
> Perhaps we seed it with initial data from project members who provide 
> services, so we have something at launch time other than fake data.
>
> 5) Once approved, we go live.  The legacy project buried this under 
> the "support" page, but I think we should offer a more prominent 
> location, perhaps a link on the home page.
>
> 6) Promote via blog, social networking, etc.
>
> 7) PMC reviews incoming submissions, etc.  Routine maintenance.
>
> Note: this same approach (Submission instructions page + XML/XSLT to 
> generate user-facing XHTML page) would also work very nicely for a CD 
> Distributor listing page.  It should be possible to copy this 
> approach, including the XSLT script, even including this note, and 
> with some modifications reuse it for that purpose.
>
> Regards,
>
> -Rob


Mime
View raw message