On Wed, Sep 26, 2012 at 5:00 PM, Rob Weir <robw...@apache.org> wrote:
> On Wed, Sep 26, 2012 at 6:59 PM, Kay Schenk <kay.sch...@gmail.com> wrote: > > see inline below... > > > > > > On 09/26/2012 02:25 PM, Rob Weir wrote: > >> > >> 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. > > > > > > 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 <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. > > > > > > 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. > > > > In general I think our current support page is confusing and > unhelpful. Too much text on one page and outdated, broken links. > I bet 99% of the visitors to this page are looking for a short list of > items, like support forum or documentation. I count 53 links on that > page, and that ignores the navigation links. Adding a 54th link for > consultants would condemn that page to perpetual obscurity, > OK. We should definitely "clean this up" if this is the case. Early on, I had tested out some of the links, and most were still working. This may no longer be the case. > > > 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. > > > > Or radical simplification of that page to our best support options and > put the other links off on an "other.html" page. But that is another > issue, slightly out of scope of what I'm volunteering to do at the > momen > That seems reasonable, esp for something like the "Books" listing. My main concern was to not highlight commercial support entities via a direct link from the home page over other types of support. It seems we might need further discussion on this aspect. > -Rob > > > > > > >>>>> > >>>>> 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 > -- ---------------------------------------------------------------------------------------- MzK "Just 'cause you got the monkey off your back doesn't mean the circus has left town." -- George Carlin