Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remaining formatting issues in tables #746

Closed
Remi-Gau opened this issue Mar 5, 2021 · 3 comments · Fixed by #998
Closed

Remaining formatting issues in tables #746

Remi-Gau opened this issue Mar 5, 2021 · 3 comments · Fixed by #998
Labels
formatting Aesthetics and formatting of the spec

Comments

@Remi-Gau
Copy link
Collaborator

Remi-Gau commented Mar 5, 2021

2 other issues I have noticed that make my inner OCD unhappy:

  • inconsistency in the format of the table headers in the spec: most of the time it is in bold but not always
  • numeric examples in the tables concerning the content of json files are not "highlighted" and might not be as obvious to the reader.

For example

Number of EEG channels included in the recording (for example, 128).

Should probably be:

Number of EEG channels included in the recording (for example, `128`).
  • inconsistencies in the rendering of string and numeric values for tables (mostly for stings)

Sometimes examples are written:

like this

and other times

`like that`
Column name Requirement level Description
name REQUIRED Channel name (for example, FC1, Cz)
units REQUIRED Physical unit of the value represented in this channel, for example, V for Volt, or fT/cm for femto Tesla per centimeter (see Units).

Originally posted by @Remi-Gau in #739 (comment)

@sappelhoff sappelhoff added formatting Aesthetics and formatting of the spec good first issue Good for newcomers labels May 14, 2021
@sappelhoff
Copy link
Member

just noticed a similar "formatting" related PR: #786

I think if we don't put CIs into place to catch these soft, style related things, it'll be hard to maintain.

@Remi-Gau
Copy link
Collaborator Author

just noticed a similar "formatting" related PR: #786

I think if we don't put CIs into place to catch these soft, style related things, it'll be hard to maintain.

Agreed. Though regarding the CI part we have to keep in mind that possibly a lot of this will be "encoded" in the metadata part of the awesome schema that @tsalo is working on.

So the style check will probably have to be done on some intermediate files after the macros are applied, no? I think you did some similar magic recently, am I right?

@sappelhoff
Copy link
Member

sappelhoff commented Jul 20, 2021

Agreed. Though regarding the CI part we have to keep in mind that possibly a lot of this will be "encoded" in the metadata part of the awesome schema that @tsalo is working on.

Indeed, and I think between Taylor and me we managed to purge a few more styling "bugs".

So the style check will probably have to be done on some intermediate files after the macros are applied, no?

Yes, since #774 these kinds of styling "bugs" would have to be fixed in the schema files ... OR on the spec after the schema is applied. --> But I think running a CI on the YAML file "descriptions" would be nicer:

description: |
Text acknowledging contributions of individuals or institutions beyond
those listed in Authors or Funding.

We just need someone to spend a couple of "minutes to hours"™ to write a script and a GitHub Action to run it 😎

EDIT: I think this is starting to become too technical for a "good first issue"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
formatting Aesthetics and formatting of the spec
Projects
None yet
2 participants