- This Charter: https://github.com/w3c-cg/r2c2/blob/main/Charter.md
- Previous Charter: N/A
- Start Date: 2024-02-01 [{TBD estimation}]
- Last Modified: (see github history)
The mission of the RDF Rust Common Crates (R2C2) Community Group is to develop a common API for working with RDF in Rust, published as a set of library crates. The goal is to improve the interoperability of the RDF ecosystem in Rust.
The common API developed by the Community Group will be defined as a set of traits and/or lightweight type, that other crates are encouraged to implement and reuse, so that data values produced by an implementation can be reused by another one.
For example, the triples produced by a Turtle parser, provided that they implement a trait defined by this Community Group, could be ingested by any independently developed implementation of a graph store. Similarly, if the latter implements the appropriate traits, it could be checked by any independently developed SHACL validator.
As much as possible, the crates developed by the Community Group should aim at fulfilling the zero-cost abstraction motto: the provided traits should ideally be generic enough, to be directly implementable by any specific implementation, regardless of its internal design (as opposed to requiring a wrapper type). However, overly generic code can be hard too use in practice, so the Community Group will have to strike a balance between genericity and usability.
The Community Group may also develop utility library crates, i.e., crates providing common types or functions expected to be pervasively used in the implementations of the common API. For example, the Community Group may produce a crate for parsing and resolving IRIs.
- develop an complete implementation of RDF-related standards
The main deliverables of the community group are Rust library crates, which should eventually be published on the standard repository https://crates.io/.
The public API of the code will be extensively documented using doc comments, and will include practical working examples.
No Specifications will be produced under the current charter.
The community group may produce a user manual, or other kind of documentation, for the produced crates.
- the RDF Javascript Libraries Community Group has a similar goal to this Community Group, applied to the Javascript programming language. Interaction between the two groups could be mutually valuable, to share experience and lessons learned.
- all projects implementing RDF (or related standards) is a potential candidate for implementing the R2C2 traits. The Community Group will strive to include the maintainers of these project in the discussions.
The group operates under the Community and Business Group Process. Terms in this Charter that conflict with those of the Community and Business Group Process are void.
As with other Community Groups, W3C seeks organizational licensing commitments under the W3C Community Contributor License Agreement (CLA). When people request to participate without representing their organization's legal interests, W3C will in general approve those requests for this group with the following understanding: W3C will seek and expect an organizational commitment under the CLA starting with the individual's first request to make a contribution to a group Deliverable. The section on Contribution Mechanics describes how W3C expects to monitor these contribution requests.
The W3C Code of Ethics and Professional Conduct applies to participation in this group.
Substantive Contributions to Specifications can only be made by Community Group Participants who have agreed to the W3C Community Contributor License Agreement (CLA).
Deliverables created in the Community Group must use the W3C Software and Document License.
Community Group participants agree to make all contributions in the GitHub repository the group is using for the particular source code or document. This may be in the form of a pull request (preferred), by raising an issue, or by adding a comment to an existing issue.
All GitHub repositories attached to the Community Group must contain a copy of the CONTRIBUTING and LICENSE files.
The group will conduct all of its technical work in public. If the group uses GitHub, all technical work will occur in its GitHub repositories (and not in mailing list discussions). This is to ensure contributions can be tracked through a software tool.
Meetings may be restricted to Community Group participants, but a public summary or minutes must be posted to the group's public mailing list, or to a GitHub issue if the group uses GitHub.
This group will seek to make decisions where there is consensus, as described in this section.
- Every work item (crate or report) worked on by the Community Group will have a list of owners which will always include the Chairs.
- This list of owners will be recorded using GitHub's CODEOWNERS mechanism.
- Only the Chairs are the owners of the CODEOWNERS file.
- Any Community Group participant can ask to be promoted owner of a work item once a pull-request they have submitted on this work item is merged (this rule is loosely inspired by the pull-request hack).
- The Chairs may demote an owner of a work item who has not contributed (with pull-requests or reviews) to that item in the past year.
- Any Community Group participant may propose a new work item (crate or report) by making a pull-request on the Community Group's GitHub repository
with the label
new-work-item, which constitutes a call for consensus. - No less than two weeks after the pull-request was posted, the Chairs assess consensus based on the feedback on the pull-request, and record a group decision on GitHub, following Section 5.2 of the W3C process.
- If the decision is to accept the new work item, the Chairs merge the pull-request and promote its author owner of the new work item.
- Regardless of the consensus of its participant, the Community Group can not accept a work item that is not in its scope, as defined by this charter.
- Every Community Group participant will have write access to the group's GitHub repository, but merging a pull-request will require approval by at least two owners of the affected work item.
- To ensure the applicability of the rule above, pull-requests spanning multiple work items are strongly discouraged, but the Chairs may decide to allow them on a per-case basis.
- Once sufficiently approved by the appropriate owners (as defined above), a pull-request can be merged even if there is disagreement about it. Individuals who disagree with the choice are strongly encouraged to take ownership of their objection by submitting a subsequent pull-request.
- The Chairs are collectively the owners on crates.io of the crates released by the Community Group.
- To request the release of a crate on crates.io, or the publication of a report as a Final Community Group Report,
a Community Group participant opens a pull-requests or an issue with the label
request-publication, which constitutes a call for consensus. - No less than two weeks after the pull-request / issue was posted, the Chairs assess consensus based on the feedback on the pull-request, and record a group decision on GitHub, following Section 5.2 of the W3C process, and take the appropriate action to implement the decision.
- For releasing a crate where only the PATCH version is changed (i.e. the only changes compared to the previous release are backward compatible bug fixes), the delay above can be reduced to one week.
- A publication request fixing a known security issue can be accepted by the Chairs without any delay, provided that the new release only includes the fix, to the exclusion of any other pull-request merged since the last release.```
It is the Chairs' responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favour or discriminate against any group participant or their employer.
Participants in this group choose their Chair(s) and can replace their Chair(s) at any time using whatever means they prefer. However, if 5 participants, no two from the same organisation, call for an election, the group must use the following process to replace any current Chair(s) with a new Chair, consulting the Community Development Lead on election operations (e.g., voting infrastructure and using RFC 2777).
- Participants announce their candidacies. Participants have 14 days to announce their candidacies, but this period ends as soon as all participants have announced their intentions. If there is only one candidate, that person becomes the Chair. If there are two or more candidates, there is a vote. Otherwise, nothing changes.
- Participants vote. Participants have 21 days to vote for a single candidate, but this period ends as soon as all participants have voted. The individual who receives the most votes, no two from the same organisation, is elected chair. In case of a tie, RFC2777 is used to break the tie. An elected Chair may appoint co-Chairs.
Participants dissatisfied with the outcome of an election may ask the Community Development Lead to intervene. The Community Development Lead, after evaluating the election, may take any action including no action.
The group can decide to work on a proposed amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass. The group may make simple corrections to the charter such as deliverable dates by the simpler group decision process rather than this charter amendment process. The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.