fix: make precommit happy with spelling

community/events/intro.md

@@ -7,11 +7,12 @@ pyOpensci staff regularly attend community meetings (e.g. SciPy meeting, PyCon U
 In these instances, asynchronous communication and sharing of documents in an organized way is critical.
 
 ### Event documents
+
 For every meeting, pyOpenSci staff should create a Google Drive folder, located in our pyos-shared drive, where meeting documents will be stored. These documents may include talk and workshop proposals, attendee signup lists, graphics used in social media and outreach posts and more content related to the event.
 
-Before an event, pyOpenSci staff will make sure this folder is shared and supporting documents are added to it. Often the folder will be created prior to the event to store talk, Bof (birds of a feather), townhall and workshop proposals.
+Before an event, pyOpenSci staff will make sure this folder is shared and supporting documents are added to it. Often the folder will be created prior to the event to store talk, BoF (birds of a feather), Townhall and workshop proposals.
 
-:::{admonition} Team checkin prior to an event
+:::{admonition} Team check in prior to an event
 :class: note
 
 Staff should also have a short check-in prior to an event to ensure that all documents, and elements needed for the event, are shared in the right place, appropriate permissions are granted, remote support needs for the event are clarified, etc.
@@ -40,7 +41,8 @@ Prior to an in-person sprint, the following items should be created:
 
 1. A template "sign up" form, created in HubSpot and shared via a bit.ly shortlink, with data fields that we collect from participants. This allows us to track who attends and event and to followup with them after (if they wish to have communication with us after)
 1. A tabletop “card” that says pyOpenSci. You will need 2-3 cards on hand for any event in case participants are spread across a few tables. This card will be important for events like sprints, workshops and open spaces where pyOpenSci has one or more tables in a large room. It will signal to contributors that we are there and help people quickly find us.
- * The card should have a qr code that is dynamic (so we can update the url that it points to and reuse the cards). This will allow us to have participants scan the code using their phones, and add their names as participants in the event. Following the event we can then send a thank you message to each participant using MailChimp or HubSpot.
+
+* The card should have a qr code that is dynamic (so we can update the url that it points to and reuse the cards). This will allow us to have participants scan the code using their phones, and add their names as participants in the event. Following the event we can then send a thank you message to each participant using MailChimp or HubSpot.
 
 :::{todo}
 will this work for events as we will want an event name associated with it but it would be annoying to make a new card for every event? UNLESS we make a bunch at once for all events for the year?

organization/internal-documentation.md

@@ -8,6 +8,6 @@ Google Drive, a part of the pyOpenSci Google Workspace plan, is where all pyOpen
 * slides that support talks and presentations
 * and more.
 
-As a pyOpenSci staff member, you should store any documents related to pyOpenSci in the **pyos-shared** Google Shared Drive. Storing documents in the **pyos-shared** drive ensures that all pyOpenSci employees can access, edit, and use these documents. Storing these documents in the shared drive also supports program task redundancy, as the document's owner is the organization in that drive rather than an individual user. Storing documents in a shared drive owned by the organization helps pyOpenSci staff jump in and help another staff person in the event of a needed but unplanned absence (e.g., a medical emergency or an unexpected family issue).  
+As a pyOpenSci staff member, you should store any documents related to pyOpenSci in the **pyos-shared** Google Shared Drive. Storing documents in the **pyos-shared** drive ensures that all pyOpenSci employees can access, edit, and use these documents. Storing these documents in the shared drive also supports program task redundancy, as the document's owner is the organization in that drive rather than an individual user. Storing documents in a shared drive owned by the organization helps pyOpenSci staff jump in and help another staff person in the event of a needed but unplanned absence (e.g., a medical emergency or an unexpected family issue).
 
 Employees can save personal documents such as 1-on-1 agendas and notes, personal notes, and other information that does not need to be shared at the organizational level in their personal drive.

reference/meeting-notes/2018/2018-10-09-notes.md

@@ -1,4 +1,4 @@
-# 10 October 2018: JOSS / pyopensci Collaboration
+# 10 October 2018: JOSS / pyOpenSci Collaboration
 
 Attendees
 * Leah, Kylen, Arfon

reference/meeting-notes/2018/2018-12-07-notes.md

@@ -14,12 +14,12 @@ https://hackmd.io/421E2mvqRWy9yHzFGXnueA
 ## Agenda Items
 
 
-* pyopensci repo
+* pyOpenSci repo
 * 1-pager - Moore funding
 * chat with Tracy Teal (Carpentries)
 * Meet our new GRA!! Kylen!
 
-## pyopensci repo
+## pyOpenSci repo
 * will meet with Stefan (current owner) next week or the week after??
 
 ## Notes from conversation with Tracy

reference/meeting-notes/2019/2019-03-06-notes.md

@@ -38,7 +38,7 @@ Luiz: cookie cutter is a good start. we can iterate in the future as more people
     - https://goo.gl/HNBmfa
     - provide home page of dev guide: https://pyopensci.github.io/dev_guide/intro
         - Leah/Kylen add info to pyopensci.org from dev guide, one pager, etc
-        - LEAH WILL create pyopensci website and link to pyopensci.org
+        - LEAH WILL create pyOpenSci website and link to pyopensci.org
     - provide levels of involvement
         - minor: sharing of pyOpenSci with colleagues, providing contacts to other packages, coming to BOF at SciPy, add to GitHub organization
         - medium: come to a meeting, advisory board

reference/meeting-notes/2019/2019-03-14-joss-discussion-notes.md

@@ -1,4 +1,4 @@
-# pyOpenSci meeting notes: 3-14-2019 JOSS / pyopensci Collaboration
+# pyOpenSci meeting notes: 3-14-2019 JOSS / pyOpenSci Collaboration
 
 https://hackmd.io/DAiHv0QhRXCBg-P5GtDzJw#
 

reference/meeting-notes/2019/2019-05-09-notes.md

@@ -4,11 +4,10 @@ tags: pyopensci, python
 
 # pyOpenSci Meeting Notes - 9 May 2019
 
-https://hackmd.io/ewQZvQdFSteXh3OXJIJPdw
+<https://hackmd.io/ewQZvQdFSteXh3OXJIJPdw>
 
 ## Attendees
 
-
 * Leah Wasser (Earth Lab, CU Boulder)
 * Kylen Solvik (Earth Lab, CU Boulder)
 * Lindsey Heagy (Berkeley)
@@ -25,12 +24,12 @@ https://hackmd.io/ewQZvQdFSteXh3OXJIJPdw
 2. JOSS update -- partnership is in place!!
 3. SciPy bof submitted!!
 4. Review process -- where should the review template live to make it easier for people to find?
-    1. Create issues in package repo ala JOSS or do it all in the software-review repo ala rOpenSci? https://github.com/pyOpenSci/dev_guide/issues/17
-    2. Currently sits: https://www.pyopensci.org/dev_guide/appendices/templates.html#review-template
+    1. Create issues in package repo ala JOSS or do it all in the software-review repo ala rOpenSci? <https://github.com/pyOpenSci/dev_guide/issues/17>
+    2. Currently sits: <https://www.pyopensci.org/dev_guide/appendices/templates.html#review-template>
     * NEIL -- didn't have an issue finding the template. he'd like to see it in the email AND the comment for the review ... so maybe the editor should do this OR Whedon the bot could do this??
     * also in the guidances for reviewers and authors...
-    * https://pyopensci.discourse.group/
-    * Luiz: maybe create a review issue template, so the checklist doesn't need to be copied? example: https://github.com/datrs/hypercore/tree/master/.github/ISSUE_TEMPLATE
+    * <https://pyopensci.discourse.group/>
+    * Luiz: maybe create a review issue template, so the checklist doesn't need to be copied? example: <https://github.com/datrs/hypercore/tree/master/.github/ISSUE_TEMPLATE>
         * have one template for review, another for pre-review, and submissions
         * Kylen: We have issue templates for submission and pre-submission. Haven't made one for review because they are comments on existing issues, not new issues by themselves. Is there the option to create a comment template?
             * Luiz: I don't think there is... sorry, I was thinking on the JOSS structure (where there is a pre-review and a review issue)
@@ -40,39 +39,40 @@ https://hackmd.io/ewQZvQdFSteXh3OXJIJPdw
     * [rOpenSci Requirements based on a discussion with Arfon](https://hackmd.io/KxM9HK-eSo-x2nkTOSBeow)
     * [Notes from meeting with Arfon](https://hackmd.io/Vw2tyNxZQ5-PItkQFTZqhA)
     * NOAM takes the floor:
-        *  Ropensci is talking with Arfon as well. JOSS requires a zenodo doi, they want to ensure the version of the package is accepted is linked to a DOI. DOI's are relevant for JOSS but not explicitly tracked in the ropensci process. The DOI for the final version in the review is used for JOSS.
-        *  ropensci has a diagnostic package that they use to provide some feedback and it's run on submission in a standardized envt... and the bot will be able to spit out results
-        *  They've had a few scenarios where authors have requested an updated review. It's not practical... because it's resource intensive...
-    *  Current whedon functionality
-    *  * one we get feedback on the bot, send all of the input to karthik, arfon and noam
-    *  Linsdey -- dashboard with whedon -- allows them to look at editor and reviewer loads, etc etc... that is super helpful. JOSS backend might be a google sheet.
+        * Ropensci is talking with Arfon as well. JOSS requires a zenodo doi, they want to ensure the version of the package is accepted is linked to a DOI. DOI's are relevant for JOSS but not explicitly tracked in the ropensci process. The DOI for the final version in the review is used for JOSS.
+        * ropensci has a diagnostic package that they use to provide some feedback and it's run on submission in a standardized envt... and the bot will be able to spit out results
+        * They've had a few scenarios where authors have requested an updated review. It's not practical... because it's resource intensive...
+    * Current whedon functionality
+    * * one we get feedback on the bot, send all of the input to karthik, arfon and noam
+    * Linsdey -- dashboard with whedon -- allows them to look at editor and reviewer loads, etc etc... that is super helpful. JOSS backend might be a google sheet.
 
 ## JOSS vs rOpenSci Review process
+
 * JOSS process follows PLOS -- minimal requirements whereas rOpenSci is more intense process.
 * LEO: JOSS for example doesn't have (automated) test requirements. it's valuable for us to be more strict
 * LUIZ: especially considering curating packages...we want to give our stamp of approval
 
 ## Funding Opportunity support via rOpenSci
 
- * Ropensci applied for funding -- to support methods focused packages
- * aggregate, automate and document current ropensci processes
-     * how to create a review community
-     * automation
-         * creating reviewer databases
-         * Send reminders, etc - create tools to handle this and make it easy for other groups to adopt
-         * Write standards for software in a way that can be tested
-             * (Luiz) semi-relevant: https://www.thoughtworks.com/insights/blog/fitness-function-driven-development
-
-    * Noam needs a letter of support by May 16.
-        * One pager: https://docs.google.com/document/d/1kZStdLA98TvFe1_0r0IuSBPyg-PL_32wBvw599Zu4NM/edit
-    * Support:
-        * +1000 (luiz)
-        * :tada: Lindsey
-        * This addresses a huge gap! +1 Max
-        * +1 leah !!
-        * :thumbsup: Jenny
-
-6. First package review checkin: Jenny, Neil, Chris (might not make it)
+* Ropensci applied for funding -- to support methods focused packages
+* aggregate, automate and document current ropensci processes
+  * how to create a review community
+  * automation
+    * creating reviewer databases
+    * Send reminders, etc - create tools to handle this and make it easy for other groups to adopt
+    * Write standards for software in a way that can be tested
+      * (Luiz) semi-relevant: <https://www.thoughtworks.com/insights/blog/fitness-function-driven-development>
+
+  * Noam needs a letter of support by May 16.
+    * One pager: <https://docs.google.com/document/d/1kZStdLA98TvFe1_0r0IuSBPyg-PL_32wBvw599Zu4NM/edit>
+  * Support:
+    * +1000 (luiz)
+    * :tada: Lindsey
+    * This addresses a huge gap! +1 Max
+    * +1 leah !!
+    * :thumbsup: Jenny
+
+6. First package review check-in: Jenny, Neil, Chris (might not make it)
     * leah followed up with filipe. she will ping him again:)
 
 7. Second package review -- [earthpy](https://github.com/pyOpenSci/software-review/issues/3)
@@ -84,39 +84,39 @@ https://hackmd.io/ewQZvQdFSteXh3OXJIJPdw
     * Levi Wolf (of PySAL, Contextily, and Geopandas) volunteered to be a future reviewer
 8. New pre-submission inquiry! [pacifica](https://github.com/pyOpenSci/software-review/issues/2)
     * Please provide your feedback on whether we should encourage a submission in this document (be mindful this document is public so if you are not comfortable with that please email us or speak up during our meeting!!)
-    * More info might be helpful here - the provided link is https://github.com/pacifica but, that has many repos. It might be easier to review if we are reviewing one repository, rather than many repositories.
-    * The core repository is a Docker compose pipeline (https://github.com/pacifica/pacifica) composed of submodules, each of which is a package - maybe this would be hard to review?
+    * More info might be helpful here - the provided link is <https://github.com/pacifica> but, that has many repos. It might be easier to review if we are reviewing one repository, rather than many repositories.
+    * The core repository is a Docker compose pipeline (<https://github.com/pacifica/pacifica>) composed of submodules, each of which is a package - maybe this would be hard to review?
     * rOpenSci has onboarded suites of tools but also didn't accept a tool that wrapped around another language... given that would be outside of our expertise..
     * a shiny app would not be accepted nor a larger system
-    *  LUIZ: pyopensci is more for lego blocks vs .. do we want to curate small packages or packages that can work together...
-    *  NOAM: there are different ways that a python "package" could be presented. we might want to define what a package is and means...
-    *  LEO: for python there is a standard packaging schema but you could have say a web app... that has a different structure. PAcifica does seem to have a set of a few sub packages that have standard python packages..
-    *  Luiz: would we consider jupyter for example...
-    *  NEIL: we need to really define the scope of what creates a package and what we will review... perhaps we need  something that refines the scope, the type of package, how it sits within a larger envt, etc...
+    * LUIZ: pyOpenSci is more for lego blocks vs .. do we want to curate small packages or packages that can work together...
+    * NOAM: there are different ways that a python "package" could be presented. we might want to define what a package is and means...
+    * LEO: for python there is a standard packaging schema but you could have say a web app... that has a different structure. PAcifica does seem to have a set of a few sub packages that have standard python packages..
+    * Luiz: would we consider jupyter for example...
+    * NEIL: we need to really define the scope of what creates a package and what we will review... perhaps we need  something that refines the scope, the type of package, how it sits within a larger envt, etc...
 
 TODO: how do we dfeine the scope of a what a package is....
 
-9. Development glossary -- anyone want to contribute and where should we place it? https://github.com/pyOpenSci/dev_guide/issues/8
+9. Development glossary -- anyone want to contribute and where should we place it? <https://github.com/pyOpenSci/dev_guide/issues/8>
 
 10. PyCon open space feedback (Luiz)
-    - a quickstart (condensed guide)
-    - nanopore interested in contributing software, might be a good venue
-    - EBI (European Bioinformatics Institute) has lots of open source packages, but not much marketing
-    - .org website feedback
-        - Link discourse to the main page of pyopensci.org: https://pyopensci.discourse.group/
-        - .org website -- too overwhelming for someone new??
-
-    - accept submissions to pyOpenSci that are already JOSS papers?
+    * a quickstart (condensed guide)
+    * nanopore interested in contributing software, might be a good venue
+    * EBI (European Bioinformatics Institute) has lots of open source packages, but not much marketing
+    * .org website feedback
+        * Link discourse to the main page of pyopensci.org: <https://pyopensci.discourse.group/>
+        * .org website -- too overwhelming for someone new??
+
+    * accept submissions to pyOpenSci that are already JOSS papers?
       * another fast track?
       * makes sense for the "curated packages" approach
-    - requirements?
-      - code coverage? (no)
-          - ropensci doesn't have a % coverage but automated testing and CI is required. The code coverage is required to be reported. if the coverage is low, you have to justify it to the editor...
-      - stable versions (semantic versioning?)
-      - Link to current reqs: https://www.pyopensci.org/dev_guide/packaging/packaging_guide.html#overview
-
+    * requirements?
+      * code coverage? (no)
+          * ropensci doesn't have a % coverage but automated testing and CI is required. The code coverage is required to be reported. if the coverage is low, you have to justify it to the editor...
+      * stable versions (semantic versioning?)
+      * Link to current reqs: <https://www.pyopensci.org/dev_guide/packaging/packaging_guide.html#overview>
 
 ## To Do Takeaways - For Everyone
+
 1. Please review the whedon bot requirements and give us feedback
     2. email to arfon, karthik and noam about whatever our requirements end up being for whedon.
 3. Please review the pacifica submission and provide your input

reference/meeting-notes/2019/2019-05-30-notes.md

@@ -123,7 +123,7 @@ other option - code for science and society -- but neil things they are more foc
 
 1. Updates: 6 packages in the submission queue!
 
-* [pacifica](https://github.com/pyOpenSci/software-review/issues/2) -- we need to make a decision on it. it's an envt / set of tools. So the question at hand is DOES pyopensci accept these types of submissions? Or do we prefer individual submissions at this point. It would be good to decide this week
+* [pacifica](https://github.com/pyOpenSci/software-review/issues/2) -- we need to make a decision on it. it's an envt / set of tools. So the question at hand is DOES pyOpenSci accept these types of submissions? Or do we prefer individual submissions at this point. It would be good to decide this week
     * Luiz: I think it's a good submission in the future, but it's a really hard submission at the moment (due to complexity).
     * https://github.com/pyOpenSci/software-review/issues/2#issuecomment-494076938
     * filipe -- maybe a platform is a bit much for us to review