All content on the UN/CEFACT github is free to use. Repositories are tagged with the license type that is applicable, usually GPL3.
- All IP is owned by UN/CEFACT and so, if you wish to contribute to any repository you must first become a registered UN/CEFACT expert join here which will require that you accept the UN/CEFACT IPR policy
- Once you have been approved by your country head of delegation as a UN/CEFACT expert then you may request contributor status on any repository via the relevant slack channel.
- To make a contribution, raise a pull request on the relevant repository. Note that, in most cases, the pull request should be preceded by raising an issue and having a conversation with the community about that issue. Pull requests should reference the relevant issue.
All specifications will be tagged with a status that defines usability for implementers.
| Status | Definition | Usage |
|---|---|---|
 |
Every new standard or major version starts with raw status | experimental use only |
 |
When a standard is completed and testable then it becomes draft | suitable for beta testing |
 |
When at least two successful implementations have passed conformance testing then the standard becomes stable. | safe to implement in production systems |
 |
When a sstandard is superseded by a new major version then the previous major version is deprecated | may still be used in production but should not be used for new builds |
 |
when a standard is obsolete and should no longer be used in any production deployment then it becomes retired | remains on this site for historical reference puposes |
 |
Usually applies to unsuccessful standards that never made it to stable status | Will be removed from this site |
All poblications (both standards and software) will follow semver conventions with a major.minor.patch version numbering system (eg version 1.5.3). The following rules apply to versioning
| Version level | definition |
|---|---|
| major | a breaking change that requires a change to consumer systems |
| minor | a functional change or enhancement that is non breaking (eg a new optional property in an API) |
| patch | a non functional change such as a documentation update |
- Specifications will follow IETF "MUST", "SHOULD" "MAY" language so that it's clear what a conforming implementation means. We will also aim to provide free open source conformance testing tools so that you may test your implementations.
- voluntary comminity support is available via the relevant slack channel and repository issues list.