Merge branch 'main' into blog-mystmd

.readthedocs.yml

@@ -1,7 +1,7 @@
 version: 2
 
 build:
-  os: ubuntu-22.04
+  os: "ubuntu-22.04"
   tools:
     python: "3.11"
 

docs/blog/2023/new-project-members.md

@@ -0,0 +1,35 @@
+# Expanding our team and the next phase of Executable Books development
+
+```{post} 2023-11-28
+:author: Chris Holdgraf
+:image: 1
+:excerpt: 2
+```
+
+Over the past three years, the Executable Books team has focused its efforts on building a Sphinx-based technical stack underlying the Jupyter Book project. This has been extremely successful, and Jupyter Book and the associated MyST ecosystem in Sphinx have gained adoption across both scientific and open source communities. The MyST Parser for Sphinx averages around 350,000 downloads a month, which makes up about 13% of all Sphinx downloads ([https://www.pepy.tech/projects/myst-parser?versions=*](https://www.pepy.tech/projects/myst-parser?versions=*)). There are over 4000 Jupyter Books in public GitHub repositories ([https://github.com/search?q=%22format%3A+jb-book%22&type=code](https://github.com/search?q=%22format%3A+jb-book%22&type=code)), many of which are now featured at [gallery.executablebooks.org](https://executablebooks.org/en/latest/gallery/).
+
+![Stargazer counts over time for Jupyter Book and MyST Parser](../images/grant-star-timeline.png)
+
+Earlier this year, we shared some [exciting new work in the Javascript stack of the MyST ecosystem](https://executablebooks.org/en/latest/blog/2023-02-09-announce-mystjs/). This aims to bring the entire Executable Books stack into a more modern technical foundation, create a more sustainable and scalable community of development, and unlock new workflows in communicating with computational narratives, especially in scientific publishing.
+
+Over the past year we’ve continued to push this effort forward, and are excited to announce a few personnel changes to the project’s grant team in order to advance this effort further.
+
+
+## Rowan Cockett is joining the Executable Books steering council
+
+The Executable Books steering council has elected Rowan Cockett to join [our Steering Council](https://compass.executablebooks.org/en/latest/team/index.html#steering-council). Rowan will be the project’s first Steerco member that is not a Principle Investigator on the project’s original grant. Rowan brings expertise in modern web-based technology for scientific communication and computational narratives. He has made extensive contributions to the project over the past several years, and has led several major strategic efforts in defining new directions for our technical stack. He has also been an excellent collaborator and has exemplified our values of building an inclusive and participatory development culture. We’re excited to work with Rowan on the Steering Council, and look forward to his leadership in moving the project forward.
+
+
+## Angus Hollands is joining the 2i2c team
+
+We’re also pleased to announce that Angus Hollands will spend the next year dedicating his time to development and community management within the Executable Books project. He’ll do so via a new position with [2i2c](https://2i2c.org), one of the collaborating organizations represented on the Executable Books steering council. We'll use the final remaining funds in the project's grant to fund Angus' time.
+
+Angus will focus his efforts on three key areas of the Executable Books ecosystem:
+
+**Technical parity with Sphinx.** We wish to explore using MyST’s documentation engine as a back-end for Jupyter Book. As part of this, Angus will aim to bring MyST’s engine up to parity with the major functionality of Jupyter Book’s current implementation with Sphinx.
+
+**User community adoption.** As part of this effort, Angus will work with key user communities to adopt the MyST documentation back-end, make any necessary changes to their content to utilize the new MyST backend, and identify friction points that can be resolved with documentation or development.
+
+**Developer community growth.** Finally, Angus will work with other Steering Council and project members to lay a foundation for the Executable Books _organization_ moving forward, including identifying a fiscal home for the project and developing our initial contributing policies and guidelines as we begin opening up the project for formal participation from the broader community.
+
+We hope that this gives a picture of the progress that we’ve made in the last few years, where our project stands now, and where we are deploying the final resources of our grant in pursuit of our goals to create open tools for communicating computational narratives. We’re excited to have Rowan and Angus joining the team in a formal capacity, and look forward to the great work that they’ll do.

docs/contribute.md

@@ -9,7 +9,7 @@ It also has a lot of information about how to contribute.
 
 ## Code of conduct
 
-We expect all contributors to this project to [follow our Code of Conduct](tc:code-of-conduct).
+We expect all contributors to this project to [](inv:tc#code-of-conduct).
 
 ## Where we work
 
@@ -22,19 +22,19 @@ Generally speaking, our contribution workflow looks someting like this:
 - **Conduct free-form conversation and brainstorming in our forum**. We have [a community forum](https://github.com/executablebooks/meta/discussions) for general discussion that does not necessarily require a change to our code or documentation.
 - **Discuss and propose changes in issues**. Issues are a way for us to agree on a problem to solve, and align on a way to solve it. They should invite broad feedback and be as explicit as possible when making formal proposals.
 - **Make a pull request to implement an idea**. We use Pull Requests to formally propose changes to our code or documentation. These generally point to an issue and ideally will close it.
-- **Iterate on the pull request and merge**. Pull Requests should have discussion and feedback from at least one core team member, and ideally from many. Once the PR is ready to merge, a core team member may decide to do so. See [our decision-making guide for formal details](tc:governance).
+- **Iterate on the pull request and merge**. Pull Requests should have discussion and feedback from at least one core team member, and ideally from many. Once the PR is ready to merge, a core team member may decide to do so. See [our decision-making guide for formal details](inv:tc#governance).
 
 This describes the high-level process that is usually followed.
 In practice, we recommend attempting a contribution to get a feel for how it works in practice.
 
 ## How we are structured
 
-Our [Team page](tc:team) lists all of the teams and their members.
-In addition, [our Governance page](tc:governance) describes the responsibilities and authority that team members have.
+Our [Team page](inv:tc#team) lists all of the teams and their members.
+In addition, [our Governance page](inv:tc#governance) describes the responsibilities and authority that team members have.
 
 ## How we make decisions
 
-Our [governance page](tc:governance) describes our formal decision-making processes.
+Our [governance page](inv:tc#governance) describes our formal decision-making processes.
 
 ## Development conventions
 

docs/gallery.yml

@@ -47,7 +47,7 @@
   repository: https://github.com/liuhuanshuo/zaoqi-book
   image: https://pandas.liuzaoqi.com/_static/mylogo.png
 - name: The Data Science Interview Book
-  website: https://dipranjan.github.io/dsinterviewqns/intro.html
+  website: https://book.thedatascienceinterviewproject.com
   repository: https://github.com/dipranjan/dsinterviewqns
   image: https://raw.githubusercontent.com/dipranjan/dsinterviewqns/master/logo.gif
 - name: Coding for Economists
@@ -194,10 +194,6 @@
   repository: https://github.com/rafneta/CienciaDatosPythonCIDE
   image: https://raw.githubusercontent.com/rafneta/CienciaDatosPythonCIDE/master/docs/logo.jpg
   website: https://rafneta.github.io/CienciaDatosPythonCIDE/intro.html
-- name: "Development Data Partnership"
-  repository:
-  image: https://raw.githubusercontent.com/datapartnership/welcome/master/images/logo.png
-  website: https://docs.datapartnership.org
 - name: "OpenPifPaf Guide"
   image: https://openpifpaf.github.io/_static/logo.png
   website: https://openpifpaf.github.io

docs/index.md

@@ -153,4 +153,4 @@ _Below is a list of recent blog posts from [our blog](blog.md)_
 
 ## Acknowledgements
 
-See our [organizational contributions page](tc:contributions) as well as [our team members page](tc:team) for a list of individuals and organizations that have made formal contributions to this community.
+See our {ref}`organizational contributions page <tc:contributions>` as well as {ref}`our team members page <tc:team>` for a list of individuals and organizations that have made formal contributions to this community.

docs/tools.md

@@ -140,8 +140,8 @@ Here are its main features:
 - Follows the __[CommonMark spec](http://spec.commonmark.org/)__ for baseline parsing
 - Configurable syntax: You can add new rules and even replace existing ones
 - Pluggable: Adds syntax extensions to extend the parser (see the [plugin list](https://markdown-it-py.readthedocs.io/en/latest/plugins.html#md-plugins))
-- High speed (see our [benchmarking tests](https://markdown-it-py.readthedocs.io/en/latest/other.html#performance))
-- [Safe by default](https://markdown-it-py.readthedocs.io/en/latest/other.html#security)
+- High speed (see our [benchmarking tests](https://markdown-it-py.readthedocs.io/en/latest/performance.html))
+- [Safe by default](https://markdown-it-py.readthedocs.io/en/latest/security.html)
 
 
 ## JavaScript stack