Formulate requirements for CLARIAH software and CLARIAH infrastructure

[proycon]

We need to formulate requirements of what it means, technically, for software to be CLARIAH software and what we expect from our software providers and infrastructure providers. Such an intention was formulated in the internal memo "CLARIAH compatibiliteit (20210412)", with the aim to deliver "CLARIAH compatibility guidelines v1.0" in Q4 2021. I'm attempting to start actually formulating these requirements in the requirements branch of this repository, and heavily draw from NDE's infrastructure requirements by @ddeboer and from my earlier work in CLARIAH-CORE regarding software quality and sustainability. See the following:

• Software and Service Requirements - Aimed at software developers/technology providers.
• Infrastructure Requirements - Aimed at infrastructure operators/providers.

This is an invitation to everybody who feels compelled to contribute, everything at this stage is simply an initial proposal and all input is welcome, you can use this issue for comments/questions/feedback or even commit directly to the requirements branch with your additions (pull requests also welcome for possibly larger/controversial changes).

Furthermore, we have a first global schematic overview of certain aspects of the infrastructure in the CLaaS architecture schema discussed in issue #3 and at the past TC meeting. Some of the initial requirements proposed are derived from the apparent consensus at that meeting.

(Edit: Links updated to reflect situation after merge of #5)

[proycon]

@ddeboer: as you see the infrastructure requirements are just a fork of your work with minor adaptations, what license do you want to attach to it? (I should have asked this before forking probably ;) )

[ddeboer]

@proycon Good to see movement on this!

Yes, please go ahead and use my document as a basis for the infrastructure requirements; great to have NDE and CLARIAH aligned here.

what license do you want to attach to it?

My mistake really, because I hadn’t yet added a license in the original repo; just did: NDE uses EUPL-1.2.

As an aside, I suggest to create a (draft) PR for the requirements branch right away. A PR gives the changes more visibility and enables readers to comment inline.

As another aside, I prefer to work in smallish increments. Why not create a separate PRs for the infrastructure and for the software requirements?

[proycon]

Good to see movement on this!

Yes, I think we just have start and see where the ship sails.

just did: NDE uses EUPL-1.2.

Great!

As an aside, I suggest to create a (draft) PR for the requirements branch right away. A PR gives the changes more visibility and > enables readers to comment inline.

Good idea yes, I was already contemplating that, I'll make one.

As another aside, I prefer to work in smallish increments. Why not create a separate PRs for the infrastructure and for the
software requirements?

That makes sense yes, but there is a lot of cross-linking between the two though: they often describe the same thing from a slightly different perspective and I try to explicitly link them. Keeping it at one simplifies things a bit.

I'm also a bit afraid to confuse and scatter contributors who might not be as git/github-savvy, it seems it poses a threshold for some. But considering the technical nature of these requirements, I assume we're all comfortable enough to handle one branch and one associated work-in-progress PR.

[hayco]

The CLARIN switchboard aims to direct a user with a given data file to useful services. Participation is encouraged.

I would discourage (pun intended) to add vocabulary (i.c. encouraged) to the already existing RFC terminology like 'recommended','optional'. Even though encouraged currently is not emphasized in the actual document (emphasis in this comment mine), I would either change this to one of {recommended,optional} or re-word the phrase, or remove the phrase.

[ddeboer]

Now the requirements are merged, let’s close this issue and continue discussion about them in more specific issues/PRs.