Apply prettier formatting

.github/config/mdcheck.json

@@ -4,7 +4,7 @@
       "pattern": "/assets/CWP-Charge-HSF.pdf"
     },
     {
-        "pattern": "mailto:.*"
+      "pattern": "mailto:.*"
     }
   ],
   "replacementPatterns": [
@@ -23,4 +23,3 @@
   "fallbackRetryDelay": "30s",
   "aliveStatusCodes": [200, 206]
 }
-

.github/workflows/README.md

@@ -2,23 +2,23 @@
 
 ## Link Checker
 
-The link checker action runs though the `link_check.yaml`
-action file.
+The link checker action runs though the `link_check.yaml` action file.
 
-The underlying checker is from Tom Cort, 
-[markdown-link-check](https://github.com/tcort/markdown-link-check). This
-is wrapped by Gaurav Nelson's [github-action-markdown-link-check](https://github.com/gaurav-nelson/github-action-markdown-link-check).
+The underlying checker is from Tom Cort,
+[markdown-link-check](https://github.com/tcort/markdown-link-check). This is
+wrapped by Gaurav Nelson's
+[github-action-markdown-link-check](https://github.com/gaurav-nelson/github-action-markdown-link-check).
 
-Note this checker checks markdown files directly, thus it will not check any links
-in `html` files on the site. To deal with the fact that Jekyll builds the site
-and creates pages from the markdown, thus internal links from `page.md` become
-`page.html`, Jekyll is run first to build the site and then internal links
-are mapped into `_site`.
+Note this checker checks markdown files directly, thus it will not check any
+links in `html` files on the site. To deal with the fact that Jekyll builds the
+site and creates pages from the markdown, thus internal links from `page.md`
+become `page.html`, Jekyll is run first to build the site and then internal
+links are mapped into `_site`.
 
 As this action is principally to make partial checks on pull requests the
 `check-modified-files-only` option is set, which will avoid most false positives
 from ephemeral website glitches. See the configuration file `mdcheck.json`.
 Should some links need to be masked, this can be done by setting an
-`ignorePatterns` in the configuration file or adding some 
+`ignorePatterns` in the configuration file or adding some
 [disabling comments](https://github.com/tcort/markdown-link-check#disable-comments)
 to the markdown page to be checked.

.github/workflows/link_check.yaml

@@ -18,7 +18,7 @@ jobs:
       - name: actions link checker
         uses: gaurav-nelson/github-action-markdown-link-check@v1
         with:
-          config-file: '.github/config/mdcheck.json'
-          check-modified-files-only: 'yes'
-          use-verbose-mode: 'yes'
-          base-branch: 'main'
+          config-file: ".github/config/mdcheck.json"
+          check-modified-files-only: "yes"
+          use-verbose-mode: "yes"
+          base-branch: "main"

.pre-commit-config.yaml

@@ -1,23 +1,29 @@
 repos:
--   repo: https://github.com/klieret/jekyll-relative-url-check
+  - repo: https://github.com/klieret/jekyll-relative-url-check
     rev: v2.0.1
     hooks:
-    -   id: jekyll-relative-url-check-html
-    -   id: jekyll-relative-url-check-markdown
--   repo: https://github.com/codespell-project/codespell
-    rev: 'v2.2.5'
+      - id: jekyll-relative-url-check-html
+      - id: jekyll-relative-url-check-markdown
+  - repo: https://github.com/codespell-project/codespell
+    rev: "v2.2.5"
     hooks:
-    -   id: codespell
+      - id: codespell
         args: ["-I", "codespell.txt"]
         types_or: ["markdown"]
-        exclude: '(organization/_posts/2016/.*)|(organization/_posts/2017/.*)|(organization/_posts/2018/.*)|(organization/_posts/2019/.*)|(organization/_posts/2020/.*)|(organization/_posts/2021/.*)|(organization/_posts/2022/.*)'
--   repo: https://github.com/pre-commit/pre-commit-hooks
+        exclude: "(organization/_posts/2016/.*)|(organization/_posts/2017/.*)|(organization/_posts/2018/.*)|(organization/_posts/2019/.*)|(organization/_posts/2020/.*)|(organization/_posts/2021/.*)|(organization/_posts/2022/.*)"
+  - repo: https://github.com/pre-commit/pre-commit-hooks
     rev: v4.4.0
     hooks:
-    -   id: check-json
-    -   id: check-yaml
-    -   id: check-case-conflict
+      - id: check-json
+      - id: check-yaml
+      - id: check-case-conflict
 
-ci:
-    autoupdate_schedule: monthly
+  - repo: https://github.com/pre-commit/mirrors-prettier
+    rev: "v3.0.0"
+    hooks:
+      - id: prettier
+        types_or: [yaml, markdown, scss, javascript, json]
+        args: [--prose-wrap=always]
 
+ci:
+  autoupdate_schedule: monthly

README.md

@@ -1,5 +1,6 @@
 # hsf.github.io
+
 HEP Software Foundation github site
 
-* Live at https://hepsoftwarefoundation.org/
-* [Website howto/documentation](https://hepsoftwarefoundation.org/howto-website.html)
+- Live at https://hepsoftwarefoundation.org/
+- [Website howto/documentation](https://hepsoftwarefoundation.org/howto-website.html)

Schools/_posts/2020-06-07-tCSC.md

@@ -8,4 +8,5 @@ layout: event
 categories: Schools
 deadline: 27 February 2020
 ---
+
 [Thematic CERN School of Computing 2020](https://indico.cern.ch/event/861566/program)

Schools/_posts/2020-07-16-MLHEP.md

@@ -7,5 +7,5 @@ author: Kilian Lieret
 layout: event
 categories: Schools
 ---
-[Sixth Machine Learning in High Energy Physics Summer School 2020](https://indico.cern.ch/event/838377/)
 
+[Sixth Machine Learning in High Energy Physics Summer School 2020](https://indico.cern.ch/event/838377/)

Schools/events.md

@@ -6,10 +6,10 @@ title: HEP Software Training Events
 {% capture list_of_upcoming_schools %}{% include list_of_upcoming_schools.md %}{% endcapture %}
 {% capture test %}{{ list_of_upcoming_schools | strip }}{% endcapture %}
 {% if test  != "" %}
+
 ## Current and Upcoming Training Events
 
-{{ list_of_upcoming_schools }}
-{% endif %}
+{{ list_of_upcoming_schools }} {% endif %}
 
 ## Past Events
 

_activities/analysisfacilitiesforum.md

@@ -6,45 +6,75 @@ layout: plain
 
 ## Overview
 
-The Analysis Facilities (AF) Forum provides a community platform for those interested in contributing to the development of analysis facilities for use by HEP experiments, serving as a space to develop and exchange ideas. We interpret “development” in the broad sense, including the contribution of ideas from potential end users for functionality to support the analysis of HEP data, specification and planning of the facilities themselves, and technical developments needed to realize AFs. HEP experiments have their own internal processes for developing and deploying AFs; this AF Forum is intended to support and strengthen those efforts by sharing amongst a broader community the key ideas and developments. The AF Forum also collaborates with related [HSF Working Groups]({{site.baseurl}}/what_are_WGs.html), such as the [Data Analysis Working Group]({{site.baseurl}}/workinggroups/dataanalysis.html) and the [PyHEP Working Group]({{site.baseurl}}/workinggroups/pyhep.html), and with [WLCG](https://wlcg.web.cern.ch) and [IRIS-HEP](https://iris-hep.org) projects.
-
-The development of future analysis facilities is of great interest to the HEP community, with considerable recent progress. There are numerous ongoing efforts to stand up AFs that utilize new tools and techniques to help make data analysis tasks easier, more performant, and more reproducible.
+The Analysis Facilities (AF) Forum provides a community platform for those
+interested in contributing to the development of analysis facilities for use by
+HEP experiments, serving as a space to develop and exchange ideas. We interpret
+“development” in the broad sense, including the contribution of ideas from
+potential end users for functionality to support the analysis of HEP data,
+specification and planning of the facilities themselves, and technical
+developments needed to realize AFs. HEP experiments have their own internal
+processes for developing and deploying AFs; this AF Forum is intended to support
+and strengthen those efforts by sharing amongst a broader community the key
+ideas and developments. The AF Forum also collaborates with related
+[HSF Working Groups]({{site.baseurl}}/what_are_WGs.html), such as the
+[Data Analysis Working Group]({{site.baseurl}}/workinggroups/dataanalysis.html)
+and the [PyHEP Working Group]({{site.baseurl}}/workinggroups/pyhep.html), and
+with [WLCG](https://wlcg.web.cern.ch) and [IRIS-HEP](https://iris-hep.org)
+projects.
+
+The development of future analysis facilities is of great interest to the HEP
+community, with considerable recent progress. There are numerous ongoing efforts
+to stand up AFs that utilize new tools and techniques to help make data analysis
+tasks easier, more performant, and more reproducible.
 
 ## What is an Analysis Facility?
 
-We loosely define an Analysis Facility as _the infrastructure and services that provide integrated data, software and computational resources to execute one or more elements of an analysis workflow. These resources are shared among members of a virtual organization and supported by that organization._
+We loosely define an Analysis Facility as _the infrastructure and services that
+provide integrated data, software and computational resources to execute one or
+more elements of an analysis workflow. These resources are shared among members
+of a virtual organization and supported by that organization._
 
 This definition will likely evolve as informed by the AF Forum discussions.
 
 ## Inception
 
-The idea of an AF Forum was proposed during the [Future Analysis Systems and Facilities workshop](https://indico.cern.ch/event/960587), where the need for a platform for those working toward analysis facilities within HEP experiments to develop and exchange ideas was identified. 
+The idea of an AF Forum was proposed during the
+[Future Analysis Systems and Facilities workshop](https://indico.cern.ch/event/960587),
+where the need for a platform for those working toward analysis facilities
+within HEP experiments to develop and exchange ideas was identified.
 
-_Kick-starters_: Diego Ciangottini (INFN, Perugia U, CMS), Alessandra Forti (Manchester, WLCG/ATLAS), Lukas Heinrich (TUM, ATLAS), Alex Held (NYU, ATLAS), Mark Neubauer (Illinois, ATLAS), Oksana Shadura (Nebraska, CMS), Nicole Skidmore (Manchester, LHCb)
+_Kick-starters_: Diego Ciangottini (INFN, Perugia U, CMS), Alessandra Forti
+(Manchester, WLCG/ATLAS), Lukas Heinrich (TUM, ATLAS), Alex Held (NYU, ATLAS),
+Mark Neubauer (Illinois, ATLAS), Oksana Shadura (Nebraska, CMS), Nicole Skidmore
+(Manchester, LHCb)
 
 ## How do I get involved?
 
-All are welcome to join the group and participate in the discussions! Please join the
+All are welcome to join the group and participate in the discussions! Please
+join the
 
-* [Mailing List](https://groups.google.com/g/hsf-af-forum)
-* [Mattermost Team](https://mattermost.web.cern.ch/signup_user_complete/?id=ffib9ny91t8qbcdpeernf3sidy)
+- [Mailing List](https://groups.google.com/g/hsf-af-forum)
+- [Mattermost Team](https://mattermost.web.cern.ch/signup_user_complete/?id=ffib9ny91t8qbcdpeernf3sidy)
 
 ## Meetings
 
-* [AF Forum Kick-off Meeting](https://indico.cern.ch/event/1132360/) (March 25, 2022)
-* Related Links
-  * [IRIS-HEP Analysis Grand Challenge Tools Workshop](https://indico.cern.ch/event/1076231) (3-4 Nov 2021)
-  * [Future Analysis Systems and Facilities workshop](https://indico.cern.ch/event/960587) (26–27 Oct 2020)
+- [AF Forum Kick-off Meeting](https://indico.cern.ch/event/1132360/) (March
+  25, 2022)
+- Related Links
+  - [IRIS-HEP Analysis Grand Challenge Tools Workshop](https://indico.cern.ch/event/1076231)
+    (3-4 Nov 2021)
+  - [Future Analysis Systems and Facilities workshop](https://indico.cern.ch/event/960587)
+    (26–27 Oct 2020)
 
 ## Contact information
 
 For any further queries, please contact the current activity Coordinators:
 
-* Diego Ciangottini (INFN, Perugia U, CMS)
-* Alessandra Forti (Manchester, WLCG/ATLAS)
-* Lukas Heinrich (TUM, ATLAS)
-* Nicole Skidmore (Manchester, LHCb)
+- Diego Ciangottini (INFN, Perugia U, CMS)
+- Alessandra Forti (Manchester, WLCG/ATLAS)
+- Lukas Heinrich (TUM, ATLAS)
+- Nicole Skidmore (Manchester, LHCb)
 
 via the Coordinators mailing list:
 
-* <hsf-af-forum-convenors@googlegroups.com>
+- <hsf-af-forum-convenors@googlegroups.com>

_activities/conditionsdb.md

@@ -4,33 +4,47 @@ author: "Paul James Laycock"
 layout: plain
 ---
 
-Discussions between Conditions Database experts across several HEP experiments took place as part of the HSF Community White Paper process in 2016/2017, producing a white paper describing best practice for a Conditions Database schema design: HSF-CWP-2017-03 [(arXiv)](https://arxiv.org/abs/1901.05429). That document provides a starting point for continuing cross-experiment discussions.  The level of consensus across the experiments on guiding principles was very encouraging, with agreement that good design features include:
+Discussions between Conditions Database experts across several HEP experiments
+took place as part of the HSF Community White Paper process in 2016/2017,
+producing a white paper describing best practice for a Conditions Database
+schema design: HSF-CWP-2017-03 [(arXiv)](https://arxiv.org/abs/1901.05429). That
+document provides a starting point for continuing cross-experiment discussions.
+The level of consensus across the experiments on guiding principles was very
+encouraging, with agreement that good design features include:
+
+- Loose coupling between client and server using RESTful interfaces
+- The ability to cache queries as well as payloads
+- Separation of payload queries from metadata queries
+
+Importantly, the group needed to agree on a definition of “conditions data”,
+concluding that in the context of large scale NHEP computing challenges it is
+the subset of non-event data used in event-data processing, often using
+distributed computing resources. These use cases have strong connections to
+several other HSF working groups, including [Reconstruction and Software
+Triggers]({{ site.baseurl}}/workinggroups/recotrigger.html), [Detector
+Simulation]({{ site.baseurl}}/workinggroups/detsim.html), [Data
+Analysis]({{ site.baseurl}}/workinggroups/dataanalysis.html), and
+[Frameworks]({{ site.baseurl}}/workinggroups/frameworks.html). Meanwhile,
+several of those involved in the CWP work continue to discuss solutions around
+the topics of Conditions Database use cases and functionality.
 
-* Loose coupling between client and server using RESTful interfaces
-* The ability to cache queries as well as payloads
-* Separation of payload queries from metadata queries
-
-Importantly, the group needed to agree on a definition of “conditions data”, concluding that in the context of large scale NHEP computing challenges it is the subset of non-event data used in event-data processing, often using distributed computing resources.  These use cases have strong connections to several other HSF working groups, including 
-[Reconstruction and Software Triggers]({{ site.baseurl}}/workinggroups/recotrigger.html),
-[Detector Simulation]({{ site.baseurl}}/workinggroups/detsim.html),
-[Data Analysis]({{ site.baseurl}}/workinggroups/dataanalysis.html), and
-[Frameworks]({{ site.baseurl}}/workinggroups/frameworks.html).
-Meanwhile, several of those involved in the CWP work continue to discuss solutions around the topics of Conditions Database use cases and functionality.
-
-----
+---
 
 ## Coordination
 
-* Andrea Formica (ATLAS)
-* Giacomo Govi (CMS)
-* Paul Laycock (Belle II, DUNE, sPHENIX)
+- Andrea Formica (ATLAS)
+- Giacomo Govi (CMS)
+- Paul Laycock (Belle II, DUNE, sPHENIX)
 
-[Email the coordination team](mailto:Andrea.Formica@cern.ch, giacomo.govi@cern.ch, laycock@bnl.gov)
+[Email the coordination team](mailto:Andrea.Formica@cern.ch,
+giacomo.govi@cern.ch, laycock@bnl.gov)
 
-----
+---
 
 ## Goal
 
-The main goal of this HSF activity is to provide a forum for cross-experiment Conditions Database discussions with as broad an audience as possible.  By first discussing and documenting use cases and their associated functionality, one aim of the group is to then converge on an API specification with a reference implementation.
-
-
+The main goal of this HSF activity is to provide a forum for cross-experiment
+Conditions Database discussions with as broad an audience as possible. By first
+discussing and documenting use cases and their associated functionality, one aim
+of the group is to then converge on an API specification with a reference
+implementation.