-
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 guidance #47
Comments
|
It would be great to progress this since we are still directing publishers to https://www.open-contracting.org/2018/07/16/creating-managing-ocds-extensions/ which is getting quite out of date (it doesn't mention the extension explorer, for example). |
The document in CRM-3987 was drafted a couple years ago, and isn't the same level of clarity and quality as more recent documentation. Can you edit it accordingly? If possible, it'd be good to complete the above tasks, too. I had started integrating the content in July, but didn't get past the home page. The content needs to start simpler, e.g.
|
I've edited the document. Do you want to review it before I create a PR?
I'm not sure what's needed here and who the audience is - is it publishers or users? For publishers, do we need to explain the use of
I've integrated the criteria from the 'quick checks' section of the process note, but left the 'in-depth checks'. Potentially, we could add the criteria under the 'individual files' subheading to the extension registry readme.
There's a lot to integrate here and I don't think the current location is causing any problems, so I suggest we keep it as-is and open a follow-up issue on integrating it (if there is a need/demand). Does that sound good?
The guidance in this blog is more about the process for mapping additional fields than it is about using or creating extensions. I think it would fit better under https://standard.open-contracting.org/latest/en/guidance/map/#consider-using-extensions, The information that is not repeated elsewhere can be boiled down to:
What do you think?
Once the Extension Explorer is updated, we should add a note to this blog to direct readers to the updated guidance. |
No, let's integrate what you have, and we can always edit it later.
I think I intended this for the publisher, to know that they don't need to define fields for different languages, and that they can instead use the Regarding users, I think only the Project extension uses this approach for multilingual support (others use it for currency exchange or arbitrary key-value pairs, like a metric's dimensions), so I don't think we need to add anything for users here.
I'm not sure which heading you're referring to. Do you mean under each subheading under this heading in the template's repo? https://github.com/open-contracting/standard_extension_template#extension-repository-structure
Sounds good. Note that there is this other issue about moving just one section of the template out: open-contracting/standard_extension_template#37
True - sounds good to me to integrate those points.
👍 |
I've integrated the content in #67. I did this by copy-pasting the content from the Google Doc and then adding the HTML tags. Let me know if there is an easier way - the output from Google's HTML export was a mess. I chose to split the publisher and user guidance into separate pages since they serve different audiences. I've opened an issue to add guidance on multi-lingual support to the handbook: open-contracting/standard-development-handbook#250 I've opened an issue about moving content from the standard extension template: open-contracting/standard_extension_template#41 I've integrated the content from https://www.open-contracting.org/2018/01/30/fields-dont-map-first/ in open-contracting/standard#1428
Ah sorry, I was referring to the headings in the process note. I've integrated the quick checks, but left the in depth checks. My suggestion was to add the content from the individual files subheading to the extension registry readme - I hadn't thought about where exactly in the readme to put it, though. |
Right - I don't think it belongs in the registry repo, if the goal is for publishers to author good quality extensions (whether registered or not). I thought maybe it'd work better in the extension template repo (though if we move content out of there, then it probably makes sense to put it in the Extension Explorer). At any rate, can you create a follow-up issue? |
Done! |
Aha, the deployment build error reminded what I meant about multilingual support. If the Extension Explorer identifies that a field has multilingual support, it says so ("This field has multilingual support."). I'll link to https://standard.open-contracting.org/latest/en/schema/reference/#language. |
#multilingual-support
anchor)The text was updated successfully, but these errors were encountered: