see inline below...
On 09/26/2012 02:25 PM, Rob Weir wrote:
On Wed, Sep 26, 2012 at 5:14 PM, Rob Weir <[email protected]> wrote:
On Wed, Sep 26, 2012 at 5:04 PM, Donald Whytock <[email protected]> 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.
Yes, this is a very good idea!
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 <[email protected]> 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.
Why do you think this is desirable? Yeah, I remember we had this under a
"Commercial Support" heading or something like that on the "Support" page.
Maybe augmenting the current "Help" link (3rd down) with some additional
wording as to what kinds of support folks might find *on* the Support
page, and then just putting it back there? Right now it's pretty vague.
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
--
------------------------------------------------------------------------
MzK
"Just 'cause you got the monkey off your back
doesn't mean the circus has left town."
-- George Carlin
