improve page formatting and consistency of titles and links

Author: robertoostenveld

_posts/2023-09-26-release.md

@@ -13,7 +13,7 @@ FieldTrip version [20230926](http://github.com/fieldtrip/fieldtrip/releases/tag/
 - Major changes to fieldtrip2fiff to facilitate exchangeability between FieldTrip and MNE-python through the fif-file format.
 - Improvements for the support for BIDS derivatives.
 - Major improvements of the [testing framework](https://www.fieldtriptoolbox.org/development/testing/), facilitating tests to be run by people external to the DCCN.
-- Implementation of Github actions to suggest tests to run to evaluate the integrity of their Pull Requests.
+- Implementation of GitHub actions to suggest tests to run to evaluate the integrity of their Pull Requests.
 - Support for files created by the SimNIBS software.
 - Improved handling of surface/volume meshes for advanced volume conduction modelling.
 - Better user experience in ft_sourceplot.

development.md

@@ -11,16 +11,16 @@ For keeping track of new ideas, feature requests and bugs, we use an [issue trac
 
 The source code in the FieldTrip toolbox is split over multiple directories reflecting its [modular organization](/development/architecture/#modular-organization). This facilitates a separation between high-level functions that do data bookkeeping, and low-level functions that focus on the algorithms.
 
-We use a combination of tools (GitHub, Mastodon, website, mailman) that are loosely linked to each other; for example, every news item on the website is automatically tweeted. An overview is presented on the [integration](/development/integration) page.
+We use a combination of tools (GitHub, BlueSky, website, mailman) that are loosely linked to each other; for example, every news item on the website is automatically tweeted. An overview is presented on the [integration](/development/integration) page.
 
-- [Contribute to the development](/development/contribute)
+- [Contribute](/development/contribute)
 - [Guidelines](/development/guideline)
+- [Software architecture](/development/architecture)
+- [Data structures](/development/datastructure)
+- [Release and quality control](/development/releasing)
 - [Testing](/development/testing)
-- [Toolbox architecture](/development/architecture)
-- [Data Structures](/development/datastructure)
-- [Distributed computing](/development/distributed)
-- [Realtime](/development/realtime)
+- [ntegration between tools](/development/integration)
 - [Projects](/development/project)
 - [Meetings](/development/meeting)
-- [Integration](/development/integration)
-- [Software quality control and release process](/development/releasing)
+- [Real-time data processing](/development/realtime)
+- [Distributed computing](/development/distributed)

development/architecture.md

@@ -1,11 +1,11 @@
 ---
-title: Toolbox architecture and organization of the source code
+title: Software architecture
 tags: [development]
 redirect_from:
   - /development/module/
 ---
 
-# Toolbox architecture and organization of the source code
+# Software architecture
 
 {% include markup/skyblue %}
 The **[ft_examplefunction](/reference/ft_examplefunction)** provides a documented walkthrough of a typical high-level FieldTrip function that demonstrates a lot of the features presented below.

development/datastructure.md

@@ -1,11 +1,11 @@
 ---
-title: Data structures used by FieldTrip
+title: Data structures
 tags: [development]
 ---
 
-# Data structures used by FieldTrip
+# Data structures
 
-High-level FieldTrip functions usually expect input data as a MATLAB structure in a specific format, and produce output data. The data is represented as MATLAB structures which are documented in the following helper functions:
+High-level FieldTrip functions expect input data as a MATLAB structure, and produce output data as a MATLAB structure. The input and output data structures are documented in the following helper functions:
 
 - **[ft_datatype_comp](/reference/utilities/ft_datatype_comp)**
 - **[ft_datatype_dip](/reference/utilities/ft_datatype_dip)**

development/getting_started.md

@@ -11,4 +11,4 @@ There are some guidelines to aid in the continued development of the code and do
 - Guidelines for the [templates](/development/guideline/templates)
 - Guidelines for the [documentation](/development/guideline/documentation)
 - Guidelines for the [communication](/development/guideline/communication)
-- Guidelines for the [website page formatting](/development/guideline/website)
+- Guidelines for the [website syntax and formatting](/development/guideline/website)

development/guideline.md

@@ -10,13 +10,13 @@ To communicate with and reach a wide audience, we use the following channels
 - this website, for documentation
 - the email [discussion list](/discussion_list), for interactions among users to help each other out
 - [GitHub](https://github.com/fieldtrip), for interaction between developpers
-- [Mastodon](https://fosstodon.org/@fieldtriptoolbox), for release announcements and news items
+- [Mastodon](https://fosstodon.org/@fieldtriptoolbox) and [BlueSky](https://bsky.app/profile/fieldtriptoolbox.bsky.social), for release announcements and news items
 
 With each of these we reach out to a specific group FieldTrip stakeholders but - although they are partially overlapping - there is none through which we reach everyone.
 
 ## News items and releases
 
-These are to be announced on the website and on Mastodon.
+These are to be announced on the website, Mastodon and BlueSky.
 
 To add a news item to the website, please file a pull request adding a new file to the [\_posts folder on the website](https://github.com/fieldtrip/website/tree/master/_posts). See example files there for how these (markdown) files should be structured. The latest files flagged as `category: news` will, when merged, appear on the homepage.
 

development/guideline/communication.md

@@ -12,15 +12,19 @@ We use <https://jekyllrb.com> for our website. The markdown documents are hosted
 
 ## Mailman
 
-We use this for a number of email discussion lists. It is hosted by C&CZ at <http://mailman.science.ru.nl>.
+We use this for the email discussion list. It is hosted by C&CZ at <http://mailman.science.ru.nl>.
 
 ## Mastodon
 
 We use <https://fosstodon.org/@fieldtriptoolbox> to notify people about new releases and other updates.
 
+## BlueSky
+
+We use <https://bsky.app/profile/fieldtriptoolbox.bsky.social> to notify people about new releases and other updates.
+
 ## Bitly
 
-We use <https://bitly.com> to automatically create short URLs that are included in the tweets.
+We use <https://bitly.com> to automatically create short URLs that are included in social media posts.
 
 ## Shields
 
@@ -32,15 +36,15 @@ We use a YouTube [video channel](https://www.youtube.com/fieldtriptoolbox) that
 
 ## GitHub
 
-We use git and GitHub for version control of the software and of the website, and for managing external contributions. More details can be found [here](/development/git). We also maintain a copy of the repository on [BitBucket](#bitbucket) and on [Gitlab](#gitlab).
+We use git and GitHub for version control of the software and of the website, and for managing external contributions. More details can be found [here](/development/git). We also maintain a copy of the repository on [BitBucket](#bitbucket) and on [GitLab](#gitlab).
 
 If changes are pushed to GitHub, a webhook is triggered. The code for that is maintained at <https://github.com/fieldtrip/automation>.
 
 ## Bitbucket
 
 A copy of the git repository of the FieldTrip software is maintained on <https://bitbucket.org/fieldtriptoolbox/fieldtrip>, although the primary site is on [GitHub](#GitHub).
 
-## Gitlab
+## GitLab
 
 A copy of the git repository of the FieldTrip software is stored on <https://gitlab.com/fieldtrip/fieldtrip>, although the primary site is on [GitHub](#GitHub).
 
@@ -58,7 +62,7 @@ At the DCCN we have a central storage system (i.e. a large shared network drive)
 
 ## Dashboard
 
-We have a set of MATLAB and Bash scripts for regression testing. This allows to do semi-automatic runs of all the test scripts on the DCCN compute cluster. We refer to this as the [test dashboard](/development/testing). The code is hosted on [GitHub](https://github.com/fieldtrip/dashboard) and the MATLAB interface is implemented in **[ft_test](/reference/utilities/ft_test)**, which you can find in the utilities folder.
+We have a set of MATLAB and Bash scripts for regression testing that are hosted on [GitHub](https://github.com/fieldtrip/dashboard). This allows to do semi-automatic runs of all the test scripts on the DCCN compute cluster. We refer to this as the [test dashboard](/development/testing).
 
 ## Mixpanel
 
@@ -72,25 +76,25 @@ We are experimenting with [Slack](https://fieldtriptoolbox.slack.com) as a messa
 
 We use a [webdav server](https://download.fieldtriptoolbox.org) to distribute the software releases and tutorial data.
 
-## Ftp - obsolete
+## FTP - obsolete
 
-We used the DCCN [download server](https://download.fieldtriptoolbox.org/) to distribute the software releases and tutorial data.
+In the past we used an FTP server to distribute the software releases and tutorial data.
 
 ## Bugzilla - obsolete
 
 In the past we used [Bugzilla](https://www.bugzilla.org) as an "issue tracker" to maintain to-do lists, distribute work, and to support follow-up communication with users. Our bugzilla server has been discontinued in 2024. The archived bug reports and discussions are still available on <http://bugzilla.fieldtriptoolbox.org>.
 
 ## Dokuwiki - obsolete
 
-In the past we used [dokuwiki](http://dokuwiki.org/) as the CMS system for our website. In 2018 we switched to Jekyll and GitHub.
+In the past we used [dokuwiki](http://dokuwiki.org/) as the content management system (CMS) for our website. In 2018 we switched to Jekyll and GitHub.
 
 ## SVN - obsolete
 
 We used to do the development with Subversion (also known as SVN). As of February 2016 we have moved all development over to git and GitHub.
 
 ## CVS - obsolete
 
-We initially used Concurrent Versions System (CVS) as the version control system.  At a certain point we followed the example from the SPM developers and switched to SVN to facilitate collaboration between more contributors.
+We initially used the Concurrent Versions System (CVS) for software version control. At a certain point we followed the example from the SPM developers and switched to SVN to facilitate collaboration with contributors.
 
 ## Google Code - obsolete
 
@@ -110,4 +114,4 @@ We used <http://facebook.com/fieldtriptoolbox> to announce events and to post ph
 
 ## Twitter - obsolete
 
-We used <http://twitter.com/fieldtriptoolbx> to notify people about new releases and other updates. For some time we also tweeted an automatic update for every commit. We are now using Mastodon instead of Twitter.
+We used <http://twitter.com/fieldtriptoolbx> to notify people about new releases and other updates. For some time we also tweeted an automatic update for every commit. We are now using Mastodon and BlueSky instead of Twitter.

development/integration.md

@@ -208,7 +208,7 @@ However, this goal is at odds with the architecture decision to give the utiliti
 
 - For modules that are provided as separate repositories, since the modules will need more than just their own directory from the main FieldTrip repository, the module repository should be set up such that it is easy to synchronize all the needed parts from the FieldTrip repository to the module repository.
 
-**Additional recommendation** : For modules that are provided as separate repositories, create a script in the module repository that largely automates the synchronization of the various parts (submodule, utilities, tests) from FieldTrip towards the module repositories. Then use it in a Github action that automates even more steps of the synchronization. The Github action can be set to automatically run whenever a new FieldTrip release is created, or triggered manually. And can add the changes directly to the main branch of the module repository, or only create a branch-and-pull- request that is first tested independently (for instance by a github action in the module repository) before the changes are added to the main branch of the module repository. Since the source is here the main FieldTrip repository, letting this workflow run fully through automated triggers is more feasible than for the externals in FieldTrip, where the source of the changed code is outside of FieldTrip.
+**Additional recommendation** : For modules that are provided as separate repositories, create a script in the module repository that largely automates the synchronization of the various parts (submodule, utilities, tests) from FieldTrip towards the module repositories. Then use it in a GitHub action that automates even more steps of the synchronization. The GitHub action can be set to automatically run whenever a new FieldTrip release is created, or triggered manually. And can add the changes directly to the main branch of the module repository, or only create a branch-and-pull- request that is first tested independently (for instance by a github action in the module repository) before the changes are added to the main branch of the module repository. Since the source is here the main FieldTrip repository, letting this workflow run fully through automated triggers is more feasible than for the externals in FieldTrip, where the source of the changed code is outside of FieldTrip.
 
 #### 3.2.4. Externals
 

development/project/code_review.md

@@ -44,7 +44,7 @@ The following section illustrates an example where the FEMfuns pipeline is embed
 
 ### Setting-up
 
-The instructions to set up FEMfuns can be found on the [Github page](https://github.com/Donders-Institute/FEMfuns).
+The instructions to set up FEMfuns can be found on the [GitHub page](https://github.com/Donders-Institute/FEMfuns).
 Setting up is achieved in three steps:
 
 Step 1: Download Anaconda: https://docs.continuum.io/anaconda/install/