Apply suggestions from code review

Co-authored-by: Fraser Greenroyd <[email protected]>

docs/Basics/index.md

@@ -6,13 +6,13 @@ The variety of AEC (Architecture, Engineering and Construction) commercial softw
 
 BHoM proposes a central Object Model, which is a _schema_ (in other words, a dictionary of terms) on which functionality can be built. By agreeing on common terminology, the output of a script created by one person can easily be used as the input for another script. 
 
-So, at its core, the BHoM contains a collection of object definitions that we all agree on. The definitions are created by the same domain experts that use them everyday (e.g. Structural Engineers, Electrical Engineers, Architects...), and they are categorised per discipline (e.g. Structure, Architecture, ...). Each definition is simply a list of properties that an object should have (e.g. wall, beam, speaker, panel,...). We call this collection of definitions **object Models** (oMs). 
+So, at its core, the BHoM contains a collection of object definitions that we all agree on. The definitions are created by the same domain experts that use them everyday (e.g. Structural Engineers, Electrical Engineers, Architects...), and they are categorised per discipline (e.g. Structure, Architecture, ...). Each definition is simply a list of properties that an object should have (e.g. wall, beam, speaker, panel,...). We call this collection of definitions the **object Models** (oMs). 
 
 By extension, the BHoM (Building and Habitats object Model) is the collection of these **object Models** and the functionality built on top of them.
 
 ## Linking Software
 
-Across the AEC industry, regardless of our discipline, we have to work with multiple softwares during the course of any given project. Since there is rarely a simple solution to transfer the data from one software to another, we usually end up either doing it manually each time or writing some bespoke script to automate the transfer. Things get even more complex when we work across disciplines and with other collaborators. When the number of programs to deal with becomes more than just a few, this one-to-one translation solution quickly becomes intractable.
+Across the AEC industry, regardless of our discipline, we have to work with multiple softwares during the course of any given project. Since there is rarely a simple solution to transfer the data from one software to another, we usually end up either doing it manually each time or writing some bespoke script to automate the transfer. Things get even more complex when we work across disciplines and with other collaborators. When the number of software to deal with becomes more than just a few, this one-to-one translation solution quickly becomes intractable.
 
 This is where the BHoM comes in. Thanks to the central common language, it is possible to interoperate between many different programs. Instead of creating translators between every possible pair of applications, you just have to write one single translator between BHoM and a target software, to then connect to all the others.
 
@@ -23,21 +23,21 @@ We call those translators **Adapters**.
 
 
 ## Linking functionality
-Most often, AEC industry experts creates ad-hoc functions and tools when the need arises. Common examples are large, complex spreadsheets, VBA macros for Excel, but also small and large User Interface programs written in C#, Python or languages.
+Most often, AEC industry experts create ad-hoc functions and tools when the need arises. Common examples are large, complex spreadsheets, VBA macros for Excel, but also small and large User Interface programs written in C#, Python or other tools.
 
 In such a large sector, most problems you encounter are likely to have been solved before by someone in your organisation, or outside. What frequently happens is that the wheel gets reinvented. Additionally, when a script is created, it often exists in isolation, and is used only by a small group of people. 
 
 Let's take the example of a user wanting to create some functionality in an Excel macro. This has several issues:
 
 - **Maintanability issues**. Frequently, only the original creator of a Macro knows how to develop or maintain it. If they are not around and a problem arises, the Macro is often just thrown away.
 
-- **Shareability issues**. For example, if the creator of a Macro that performs some function in a spreadsheet wants to share this functionality with one of their clients, they often end up sharing the spreadsheet with the Macro in it, effectively sharing the source code and the fruit of their hard work, which ends up just being copied.
+- **Shareability issues**. For example, if the creator of a Macro that performs some function in a spreadsheet wants to share this functionality with one of their clients, they end up sharing the spreadsheet with the Macro in it, effectively sharing the source code (the fruit of their hard work), which could end up being copied.
 
 - **Scalability issues**. Macros are hard to scale. If you need to add more features or more complex functionality in a Macro, the code soon becomes unmanageable.
 
 - **Collaboration issues**. Collaborating on the code written in a Macro is a mess. Only one person can work on it at the same time. In order to merge the work of different people into a same Macro spreadsheet, either a library is created, or copy-paste is required.
 
-BHoM proposes to create a common library of functionality in **Engines**, which are simply tidy collections of functions. Like Adapters, Engines can be stored in Toolkits, which are simply GitHub repositories. GitHub repositories make it easy to share and collaborate on code (or not share, if privacy is chosen). BHoM makes it very easy to expose any functionality written in an Engine to Excel, Grasshopper or any other interface.
+BHoM proposes to create a common library of functionality in **Engine**s, which are simply tidy collections of functions. Like Adapters, Engines can be stored in Toolkits, which are simply GitHub repositories. GitHub repositories make it easy to share and collaborate on code (or not share, if privacy is chosen). BHoM makes it very easy to expose any functionality written in an Engine to Excel, Grasshopper, or other interfaces.
 
 Thanks to the BHoM being exposed in various UIs such as Grasshopper and Excel, you don't even need to know how to write code to use the functionality created by other people.