Fix: broken nav

documentation/index.md

@@ -43,7 +43,6 @@ Publish Your Docs <hosting-tools/publish-documentation-online>
 Website Hosting and Optimization <hosting-tools/website-hosting-optimizing-your-docs>
 ```
 
-
 ```{important}
 Please note that the tools discussed here are those that
 we see commonly used in the community. As tools evolve we
@@ -104,30 +103,30 @@ Python workflows. They might be new(er) to Python and/or data science. Or
 expert programmers. But they might not have a background in software
 development. These users need to know:
 
- * How to install your package
- * How to install dependencies that your package requires
- * How to get started using the code base
- * Information on how to cite your code / give you credit if they are using it
- in a research application.
- * Information on the license that your code uses so they know how they can
- or can't use the code in an operational setting.
+- How to install your package
+- How to install dependencies that your package requires
+- How to get started using the code base
+- Information on how to cite your code / give you credit if they are using it
+  in a research application.
+- Information on the license that your code uses so they know how they can
+  or can't use the code in an operational setting.
 
 ### 2. Potential tool contributors
 
 The other subset of users are more experienced and/or more engaged
 with your package. As such they are
 potential contributors. These users:
 
-* might have a software development background,
-* might also be able to contribute bug fixes to your package or updates to your documentation
-* might also just be users who will find spelling errors in your documentation, or bugs in your tutorials.
+- might have a software development background,
+- might also be able to contribute bug fixes to your package or updates to your documentation
+- might also just be users who will find spelling errors in your documentation, or bugs in your tutorials.
 
 These users need all of the things that a basic user needs. But, they
 also need to understand how you'd like for them to contribute to your
 package. These potential contributors need:
 
-* A development guide to help them understand the infrastructure used in your package repository.
-* Contributing guidelines that clarify the types of contributions that you welcome and how you'd prefer those contributions to be submitted.
+- A development guide to help them understand the infrastructure used in your package repository.
+- Contributing guidelines that clarify the types of contributions that you welcome and how you'd prefer those contributions to be submitted.
 
 ```{important}
 It's important to remember that the definition of what a contribution is can be
@@ -136,7 +135,6 @@ spelling issue in your documentation. Or it could be a code fix that includes a
 new test that covers an edge-case that they discovered.
 ```
 
-
 ## Documentation elements that pyOpenSci looks for reviewing a Python package
 
 In the pyOpenSci open peer review, we look for
@@ -149,12 +147,12 @@ that you should consider in your package's documentation in more detail.
 
 <!-- TODO: EIC checks are missing: code of conduct -->
 
-
 ```{button-link} https://www.pyopensci.org/software-peer-review/how-to/editor-in-chief-guide.html#editor-checklist-template
 :color: primary
 :class: sd-rounded-pill float-left
 View pyOpenSci peer review check list
 ```
+
 <!--
 1. Individual files in your GitHub (or GitLab) repository including:
     * [A clear and to the point **README.md** file](readme-file-best-practices) that includes information about how to cite your package.
@@ -176,16 +174,13 @@ alt: Image showing the files in the the MovingPandas GitHub repository. Files in
 An example from the MovingPandas GitHub repository with all of the major files in it including CONTRIBUTING.md, README.md, CODE_OF_CONDUCT.md and a LICENSE.txt file. *(screen shot taken Nov 23 2022)*
 ```
 
-
-
 ## What's next in this Python package documentation section?
 
 In this section of the pyOpenSci package guide, we will walk
 you through best practices for setting up
 documentation for your Python package. We will also suggest
 tools that you can use to build your user-facing documentation website.
 
-
 <!--
 Commenting this out for now - it will be moved to another section
 

index.md

@@ -153,34 +153,6 @@ Good meets the requirements. Going beyond the minimum can make package maintenan
 This guide is now a work in progress. If you have ideas of things you'd like
 to see here, [we invite you to open an issue on GitHub that details any changes or additions that you'd like to see.](https://github.com/pyOpenSci/python-package-guide/issues).
 
-```{toctree}
-:hidden:
-:caption: Documentation
-
-Documentation Overview <documentation/index>
-Write User Documentation <documentation/write-user-documentation/intro>
-Core GitHub Repository Files <documentation/repository-files/intro>
-Documentation Tools & Hosting  <documentation/hosting-tools/intro>
-```
-
-```{toctree}
-:hidden:
-:caption: Package structure & code style
-
-Manage Package Versions <package-structure-code/python-package-versions>
-Publish Package PyPI Conda <package-structure-code/publish-python-package-pypi-conda>
-Code Style & Format <package-structure-code/code-style-linting-format>
-Intro <python-packaging/intro>
-
-```
-
-```{toctree}
-:hidden:
-:caption: CI and Testing
-
-Intro <ci-and-testing/intro>
-```
-
 <!--
 COMMENTED OUT TEXT TO BE MOVED
 

package-structure-code/intro.md

@@ -9,6 +9,52 @@ there are some great modern packaging tools that ensure that you're following
 best practices. Here, we review tool features and suggest tools that might be
 best fitted for your workflow.
 
+::::{grid} 1 1 2 2
+:class-container: text-center
+:gutter: 3
+
+:::{grid-item-card}
+:link: python-package-build-tools
+:link-type: doc
+
+✨ Finding the right packaging tool(s) ✨
+^^^
+
+Learn more about the suite of packaging tools out there.
+And learn which tool might be best for you.
+:::
+
+:::{grid-item-card}
+:link: python-package-structure
+:link-type: doc
+
+✨ Package file structure ✨
+^^^
+src layout, flat layout and where should tests folders live? No matter what your level of packaging knowledge is, this page will help you decide upon a package structure that follows modern python best practices.
+:::
+
+:::{grid-item-card}
+:link: python-package-build-tools
+:link-type: doc
+
+✨ Publish to PyPI and Conda ✨
+^^^
+If you have a pure python package, it's a straight forward
+process to publish to both PyPI and then a Conda channel such as
+conda-forge. Learn more here.
+:::
+
+:::{grid-item-card}
+:link: code-style-linting-format
+:link-type: doc
+
+✨ Code style & linters ✨
+^^^
+Black, blue, flake8, Ruff - which tools can help you ensure your
+package follows best practices for code format? Learn more about the options and why this is important here.
+:::
+::::
+
 :::{figure-md} fig-target
 
 <img src="../images/python-package-tools-decision-tree.png" alt="Figure showing a decision tree with the various packaging tool front-end and back-end options." width="700px">
@@ -98,8 +144,8 @@ Complex Builds <complex-python-package-builds>
 :hidden:
 :caption: Publishing a package
 
+Publish with Conda / PyPI <publish-python-package-pypi-conda>
 Package versions <python-package-versions>
 Code style <code-style-linting-format>
-Publish <publish-python-package-pypi-conda.md>
 
 ```