-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add logos #5
Comments
@kindly as normally the users don't go to the "About" page, what if in the main page, the last sentence says "This website is in alpha and is provided on best-efforts basis by Open Data Services Co-operative" |
@yolile please can I ask: are there any OCP-published guidelines or requirements on OCDS-powered tools that are built and maintained by non-OCP parties? |
@stevieflow not really, we only have the "Powered by" OCDS logo ( that we incorporated recently) I shared with @kindly |
Indeed. We do not have such guidelines – and typically a tool author has a self-interest in clearly identifying themselves via logos, text, etc. so there hasn't been other cases of confusion. The updated text is clearer, thanks! Our only guidance is with respect to the "powered by OCDS" logo, whose purpose is similar to "powered by Sphinx", WordPress, etc. – which is to create awareness of the technology and to encourage the ecosystem. In general, we do not want to impose requirements on tool authors. But when there is confusion around authorship/control of a service, it is important to clearly state the author, so that users don't send requests for changes/help to the wrong party. |
Thanks @yolile @jpmckinney yes, it's something that has been around our open data initiatives since year dot. It's even more acute when the actual data is published independently and dispersed (as is the same for 360, IATI etc) --> we could/should be saying something like "powered by data that is independently published by a dispersed network of organisations, referring to a shared standard [insert name]" --> not very catchy, I agree!
Yes - 100% agree. Hopefully this is addressed, but we can continuously review and refine. I was just wondering (aloud) if OCP had any guidance on this, as you are often ahead of the curve. This doesn't exist in any detail via other initiatives afaik |
(this is a tangent from the purpose of this ticket - apologies) We face similar issues in other parts of our initiatives:
As our initiatives succeed this becomes more taxing. The answer could be in training, support and outreach (which need resources) rather than centralisation, licencing and compliance -- but maybe somewhere in between. It's challenging, and I don't expect OCP to have all the answers (to be clear, the "powered by OCDS" is fine!). However, it's also useful indicator if third parties are actively building, publishing and talking about the initiative, and the data it facilitates.
|
The position looks good to me, though it seems like the logo isn't rendering well.
I'm also happy to add this to help address @jpmckinney's concern about clarity of authorship. |
@stevieflow For an open standard, I don't know that there is much to stop people from using the name of the standard (or its logo) to describe data that is stale or invalid, or from writing things that are untrue of the standard. There's a lot of outdated and untrue information about any successful standard, like HTML, etc. Prevention/mitigation is the only option, using the methods you mentioned (training, support, outreach), or also promoting good sources (e.g. MDN) over worse sources (W3Schools). In the case of niche standards, the good source to invest in is the standard's own documentation. We have considered some form of time-limited certification (e.g. a support provider is "certified" for some years as being able to train others on OCDS and/or to implement OCDS), but presently it's simpler to follow more informal processes. |
thanks @jpmckinney - appreciated. Yep - it's a difficult balance. Speaking of certificates, I note https://certificates.theodi.org/en/ is still in operation (for publishers, not tools/users). We've looked at this from various angles before - but not implemented. |
Jeni Tennison has some musings on certification here: http://www.jenitennison.com/2021/05/03/april-2021-month-notes.html ODI Certificates are self-certification - more like a checklist for publishers. |
@duncandewhurst
Tried a few options and this looked the best. What do you think?
The text was updated successfully, but these errors were encountered: