General data repository about browser-compat-data HOT 8 CLOSED

I'm not at ease to mix everything in the same repo. Meta data and compat data are two different beast and I wonder if it will ease or complicate contribution of those data (My intuition goes to the latter).

At that point the question is: do we want smaller repos with each handling a single set of data or a giant repo with everything.

I'm more in favor of a set of smaller repos as it provides some serious benefits:

• Maintenance is easier on smaller chuck of data
• Embedding data is easier as you can pick just what you need

But there is also benefits to centralized repo for data

• Automation is easier
• Coherence is easier to enforce.
• Remote access is centralized

Possibly, we could have one repo per domaine (JS, API, CSS, etc.) and an extra repo using git subtrees (see the git-subrepo tool) to aggregate everything for those who prefer to have a single point of entry.

from browser-compat-data.

This is a good idea, but I'm not sure I agree with your proposed structure - it seems odd to have some categorization by the kind of data (e.g. compat) and some by the domain (e.g. css). But maybe we can just get the benefit of moving everything here now, and reorganize it later if it starts to be a problem.

from browser-compat-data.

Oh, you are absolutely right. We could totally agree on a folder structure just by domain.

from browser-compat-data.

Maintenance is easier on smaller chuck of data

Interesting, I actually find it more difficult if things are cluttered around. Currently the JSONs are somewhere in some macros. No one has a map to our open data. I don't know for sure if one "MDN open data" repository is the answer (though I like the idea, hence this proposal). In the end, I would like to standardize how we store data, either in a single repo, or in several but with a plan. Having it in one repo sounds easiest for now to me in terms of discoverability, tooling/automation, standardization efforts.

Embedding data is easier as you can pick just what you need

I don't know much about this yet. I liked your npm proposal and I would assume that we could still provide our data through different npm modules sourcing from one repo.

I noticed the raw URLs GitHub are nice already, too. I would be something like https://raw.githubusercontent.com/mdn/data/master/css/properties.json

from browser-compat-data.

I tend to agree with Jérémie. Compat data is different from spec. and meta data. I believe it encourages contribution for it if it's held in a separate repo, because all compat data will be centralized.

Also, we could write automated tests checking the compatibility and update the data.

FWIW, the people working on CSS Houdini are also discussing whether to split their repo. One argument for splitting it is that one repo "makes it really hard to inspect outstanding issues".

Sebastian

from browser-compat-data.

Alright, let's go ahead with a new repository for "spec" data. Not sure "spec-data" or "data" are ideal names, any proposal?

from browser-compat-data.

I think just "data" is fine. The data consists of more than just spec. data. E.g. it contains links to guides or grouping information.

Sebastian

from browser-compat-data.

https://github.com/mdn/data

from browser-compat-data.