This by the way means that anything you put in .bidsignore SHOULD also follow BIDS-style naming convention, right?

I would think so, yes.

okay, so let's raise an issue on bids-validator to follow up on it before merging this PR? According to this rephrasing, any file including those in .bidsignore should be of format:

key1-value1_key2-value2_..._suffix.ext

This should be easy enough to implement. I predict that at least some example datasets will fail the validator once you implement this.

SHOULD is not MUST - this is more of a recommendation than a mandate.

I also don't see the point of constraining the format of .bidsignore. Suppose I have a subdir called misc/ that contains a bunch of files that are relevant to the project, some of which are BIDS-like, some of which aren't, but none of which I want to run the validator (or some other app) against. Why would I need/want to put anything other than misc/ in .bidsignore? And if I can't specify anything other than BIDS-like patterns, that means I don't have a way of telling validators or other apps to ignore non-compliant paths I know are going to fail validation or raise warnings, which seems to defeat the point of having the .bidsignore in the first place.

Re: SHOULD vs. MAY, there isn't a fact of the matter; it's always going to be a judgment call whether someone thinks they have a good reason to ignore the recommendation. It's also going to be a judgment call at implementation: one validator may choose to raise a warning for violation of SHOULDs whereas another may not. It's true that in practice, some people are going to do the work to make non-compliant files BIDS-like, while others won't make the effort. But that's exactly the point of a non-binding recommendation: we would like you to do it, but if you don't, so be it. (To be clear, I agree that we SHOULD raise warnings in the validator for this; I just don't think it's a MUST. ;))

Yes, perhaps I was a little too flippant; adding it to the validator does provide a useful hint to curators, so there is a value. My point was more that, no tools can be expected to parse everything that might show up in a .bidsignore, so the only real thing to consider is "Will a human understand this", which is outside anything a validator can hope for.

But yes, I agree that it would be a good addition to the validator, but I think there's more value in having the language clear in the spec sooner than waiting for somebody to fix the validator giving a friendly prod. (If you'd like to submit a PR, I'd be happy to review it, although my Javascript is rusty.)

Why would I need/want to put anything other than misc/ in .bidsignore?

Yes you are right. You should be able to put misc/ in .bidsignore but I still think the validator should raise a warning for each of the files in misc/ that are not BIDS-like.

adding it to the validator does provide a useful hint to curators, so there is a value.

yes exactly, and historically we have raised warnings in the validator for SHOULD and RECOMMENDED stuff (even though not completely in a consistent way).

I think there's more value in having the language clear in the spec sooner than waiting for somebody to fix the validator giving a friendly prod.

To be clear, I'm all for clarification of the language and I don't want to stop that.

If you'd like to submit a PR, I'd be happy to review it, although my Javascript is rusty

I'd rather have someone else submit the PR so we do not have a community of people making changes to the specification faster than the tooling can keep up. I'm happy to review the PR though.

@jasmainak Just to be clear, I see this as a clarification of the present document that does not change the intended meaning, and requires no changes to any datasets or tooling. I agree with the move to propose that the validator should specifically handle this case and warn on ignored-but-unBIDSy files.

So I would suggest we go ahead and merge this and open an issue on bids-validator. Does that work for you?

okay sounds fair to me !