incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Call for comments: Webpage for Listing OpenOffice Consultants
Date Wed, 26 Sep 2012 21:25:12 GMT
On Wed, Sep 26, 2012 at 5:14 PM, Rob Weir <robweir@apache.org> wrote:
> On Wed, Sep 26, 2012 at 5:04 PM, Donald Whytock <dwhytock@gmail.com> wrote:
>> 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.
>>
>
> One policy might be that once a year (or quarter or whatever) we
> verify that the listed homepage and email address are still valid.
> Ones that fail are removed.  Of course they could be re-added if the
> resubmitted.  This is an easy-enough task if we have a listing of 20
> consultants.  Less so with 200.  Maybe could be automated.
>

Dennis will like this.  Just thought of a "poka-yoke" approach to
identifying obsolete listings.  Simply require that the logo be hosted
by the listed company.  That way, if the company moves on, there is a
good chance that the image link will break as well and this will be
obvious when looking at the listings.

> Auto-expiration could work as well, but we'd probably want to automate
> a reminder courtesy note.
>
> This is not something we need to decide right now, except maybe to say
> in the submission policy document that listings may be deleted if they
> cease to be relevant, e.g., contact information becomes invalid, etc.
>
>> 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+OpenOffice+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