Frictionless Standards (v2). Contribution Guide

[roll]

Dear Working Group members and Contributors,

For historical reasons and backward compatibility, we're keeping Frictinonless Specs (v1) as it is on its website - https://specs.frictionlessdata.io/. All the documents and profiles will live there "forever."

The Data Package Standard (v2) will be released on a new website - https://datapackage.org/ - having only core specifications included so, for example, if there is an interest of continuing to develop Fiscal Data Package (an extension) we will create or delegate a separate project for it. As the goal of v2 work is quality and readiness the limited scope is really important. As we see Data Package Standard is more and more used by leading data-world stakeholders the project needs to transit from a perceived "labs" state to a perceived (and real) "finished standard" state similarly to CSVW, JSON, and others.

Currently (2023-12-17), this repository https://github.com/frictionlessdata/datapackage, powering https://datapackage.org, contains an exact copy of v1 specifications, profiles, and patterns. During the v2 work we will be creating pull requests to this repository and asking WG for a review in #853. If a Working Group member or a Contributor wants to propose a change please create a PR to https://github.com/frictionlessdata/datapackage and ask for a review.

There is a list of issues at the moment picked to be processed for v2 - https://github.com/frictionlessdata/specs/milestone/6. This list is open so one can propose other issues. Please, let others know if starting working on a PR of any of issues. Note, that issues live in the specs repo while pull requests need to go to datapackage repo. When v2 is finished we will find non-breaking way to merge these repositories.

Links

• Specifications: https://github.com/frictionlessdata/datapackage/tree/main/content/docs/specifications
• Profiles: https://github.com/frictionlessdata/datapackage/tree/main/profiles
• Patterns: https://github.com/frictionlessdata/datapackage/tree/main/content/docs/recipes

[peterdesmet]

👍 I suggest adding a banner on every page of the current (soon to be archived) website https://specs.frictionlessdata.io/ directing readers to the v2 website.

[pwalsh]

@roll so, they won't be called the Frictionless Data Standards anymore? When I look at Data Package I find it a bit confusing as to whether Data Package refers to the Data Package Standard, or, the suite of specifications formally known as Frictionless * , where one of the standards shares the same name as the suite. That is as someone who knows this stuff fairly well, but maybe just because I have seen it through several name changes.

[roll]

@pwalsh
I really hope they won't =) Over the years all the attempts to make "Frictionless (Data) something" a user-friendly brand were honestly failing as it's very long, still not fully defined (with "data" or without), and not friendly for non-English speakers etc. Frictionless is a great name for the initiative, our collaborative org on Github, etc but for mass adoption, Data Package is just another level in my opinion: focused, short, easy to explain, and already well-known.

Having the standard partially detached from the rest of the project solves a lot of problems:

• sustainability (no matter what FD funding/etc status, the standard will be safe because it requires really little maintenance when v2 is finished)
• adoption risks (at the moment if you want to adopt https://specs.frictionlessdata.io/ you really need to go through the whole FD project to understand its status/etc.; when detached there will be no this "dependency" on implementations anymore, one will be able to use Data Package even without knowing about FD until it's needed)
• communication simplicity (at the next stage of this project we're going to work with data portals on adding datapackage.json export, and, I think it will be way easier to present it as "we just released Data Package Standard (v2) would you like to consider supporting..." rather than talking about Frictionless Data Specs/Standards)

Regarding "Data Package Standard is a set of specifications and patterns" -- I hope it won't be confusing as it's pretty aligned with original Rufus's concept:

Data Package Specs Suite
When you look more closely you’ll see that Data Package is actually a suite of specifications. This suite is made of small specs, many of them usable on their own, that you can also combine together.

PS.
Sorry for chaotic writing I was doing it in a hurry I forgot to announce that I'll be off for 2 weeks so I wish happy holidays everyone!