On Wed, Sep 26, 2012 at 5:14 PM, Rob Weir <robw...@apache.org> wrote: > On Wed, Sep 26, 2012 at 5:04 PM, Donald Whytock <dwhyt...@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 <robw...@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
