Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automate gh-pages deployment evalution_tools version tracking #49

Open
aaraney opened this issue Mar 2, 2021 · 3 comments
Open

Automate gh-pages deployment evalution_tools version tracking #49

aaraney opened this issue Mar 2, 2021 · 3 comments
Assignees
Labels
bug Something isn't working documentation Improvements or additions to documentation enhancement New feature or request

Comments

@aaraney
Copy link
Member

aaraney commented Mar 2, 2021

Evaluation tools 1.0.0 -- this is the incorrect version.

As shown, right now the version number requires manual updating. I need to explore how to improve this.

Tangentially, I think we could improve version bumping for this package and the sub-packages included. I know that bumb2version is commonly used, but I think it makes sense to do some research to find the best option.

@aaraney aaraney self-assigned this Mar 2, 2021
@aaraney aaraney added bug Something isn't working documentation Improvements or additions to documentation enhancement New feature or request labels Mar 2, 2021
@jarq6c
Copy link
Collaborator

jarq6c commented Jun 14, 2023

@aaraney kicking this dead horse to talk about docs!

From a maintenance and ease of use perspective, I would love to switch from sphinx to mkdocs/mkdocstrings. From what I've experienced the mkdocstrings plugin works best with Google style docstrings. The numpy docstrings we use will work, but aren't fully supported by mkdocstrings and tend to get a bit jumbled.

I don't mind doing a review of our documentation and converting everything to Google style. However, I thought I would give you a chance to weigh-in before doing that. I'd also use this opportunity to review all our docs and fill them out where needed (like adding Example sections).

The advantage of all this is that we can use our existing README.mds as landing pages for each subpackage and I think adding new docs and deploying to gh-pages will be much simpler and streamlined.

@aaraney
Copy link
Member Author

aaraney commented Jun 14, 2023

@aaraney kicking this dead horse to talk about docs!

Im not dead yet. Monty Python and the Holy Grail

From a maintenance and ease of use perspective, I would love to switch from sphinx to mkdocs/mkdocstrings.

Likewise! I really like mkdocs and find it much easier to use too.

I don't mind doing a review of our documentation and converting everything to Google style. However, I thought I would give you a chance to weigh-in before doing that. I'd also use this opportunity to review all our docs and fill them out where needed (like adding Example sections).

That sounds like a fair amount of work to ask of one person. I'm happy to help out if you okay with splitting out the workload?

@jarq6c
Copy link
Collaborator

jarq6c commented Jun 15, 2023

That sounds like a fair amount of work to ask of one person. I'm happy to help out if you okay with splitting out the workload?

Well, it doesn't have to be done tomorrow. Assume I initiate changes in a piecemeal fashion and ask for your review via the PR system. That way at least two sets of eyes see all the docs. Sound good?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants