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

Documentation restructuring (core submodule) #1478

Open
bmcfee opened this issue May 4, 2022 · 6 comments · May be fixed by #1801
Open

Documentation restructuring (core submodule) #1478

bmcfee opened this issue May 4, 2022 · 6 comments · May be fixed by #1801
Labels
documentation Issues relating to docstrings, examples, and documentation build good for beginners Are you new here? These issues are for you!

Comments

@bmcfee
Copy link
Member

bmcfee commented May 4, 2022

The documentation site is generally pretty navigable, but I think the core submodule (sub-heading "Core IO and DSP") is both too large and at this point, inaccurately named.

At present, it looks as follows:
image
where each of those sub-sub-headings has somewhere between 2 and 12 function entries.

I think we can easily break this up into some more meaningful sections, which can be promoted to the top level of the index. Originally, I had designed the documentation index to reflect the submodule structure of the package, but I don't think that's terribly relevant anymore.

I propose that we eliminate the "Core IO and DSP" top-level heading, and replace it with the following:

  • Signals (includes load, stream, resample, and any signal generators and helper utilities)
  • Spectral representations
  • Magnitude scaling
  • Unit conversion (time, frequency)
  • Music notation
  • Pitch and tuning
  • Harmonics
  • Phase recovery
  • Miscellaneous (collects current misc + frequency range generators)

I'm also open to other suggestions for top-level organization, but the above seems at least plausible and a bit easier to navigate IMO.

Are there other sections of the docs that could benefit from restructuring?

@bmcfee bmcfee added documentation Issues relating to docstrings, examples, and documentation build good for beginners Are you new here? These issues are for you! labels May 4, 2022
@bmcfee bmcfee added this to the 0.10.0 milestone May 4, 2022
@bmcfee bmcfee removed this from the 0.10.0 milestone Nov 15, 2022
@dana-gill
Copy link

dana-gill commented Jan 26, 2024

Hey Brian -- Dana here (my old @danagilliann is no longer accessible) 😄 I'm happy to start working on this. I can start of with

I propose that we eliminate the "Core IO and DSP" top-level heading, and replace it with the following:

  • Signals (includes load, stream, resample, and any signal generators and helper utilities)
  • Spectral representations
  • Magnitude scaling
  • Unit conversion (time, frequency)
  • Music notation
  • Pitch and tuning
  • Harmonics
  • Phase recovery
  • Miscellaneous (collects current misc + frequency range generators)

@bmcfee
Copy link
Member Author

bmcfee commented Jan 26, 2024

👋 Thanks @dana-gill , that'd be great!

@dana-gill
Copy link

I do have to admit: Building the documentation is not very easy since the documentation for it was a bit scattered 😅 Would it make sense to propose the following issues?

  1. Have a Contributing section within the sidebar. I think the easiest would be to just link it to the Contributing Page on GitHub. Maybe it could be converted to .rst some time in the future.
  2. Reference Compiling Documentation in the Contributing Page that way there's a clear path for those working on the documentation. I thought about moving the content of the Compiling Documentation into the Contributing Page, but since the Makefile does more than build the website, I think it's fine staying there

Let me know what you think :)

@bmcfee
Copy link
Member Author

bmcfee commented Jan 26, 2024

Building the documentation is not very easy since the documentation for it was a bit scattered 😅

Yeah, I know, sorry for that! It's a complicated process because we need to maintain historical doc builds, and readthedocs isn't viable for us due to the computational overhead of running all of the examples.

Have a Contributing section within the sidebar. I think the easiest would be to just link it to the Contributing Page on GitHub. Maybe it could be converted to .rst some time in the future.

If there's a way to auto-include the doc, rather than linking or converting it, that would be better. Github wants it to be CONTRIBUTING.md (though other formats might be supported) so that it's discoverable and checks off the community guidelines box.

2. Reference Compiling Documentation in the Contributing Page that way there's a clear path for those working on the documentation. I thought about moving the content of the Compiling Documentation into the Contributing Page, but since the Makefile does more than build the website, I think it's fine staying there

Yeah, that's a good idea. It could also be expanded a bit to cover the doc linting and link checking we added to the CI so that people can run that locally if they want.

@dana-gill
Copy link

dana-gill commented Jan 29, 2024

Hi @bmcfee! I created a draft PR #1801 with a preview of a possible solution to restructure the documentation side bar. Before I completely proceed with a full makeover of the sidebar, could you let me know if the general idea was what you had in mind? Here's what Phase Recovery looks like, for example:
Screenshot 2024-01-29 at 1 29 58 PM

Thanks! 🌻

@bmcfee
Copy link
Member Author

bmcfee commented Mar 12, 2024

👋 @dana-gill sorry this got buried in my notifications (I'm phasing back into full-time this week). But yeah, this looks like what I had in mind - thanks!

@dana-gill dana-gill linked a pull request Mar 27, 2024 that will close this issue
9 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Issues relating to docstrings, examples, and documentation build good for beginners Are you new here? These issues are for you!
Development

Successfully merging a pull request may close this issue.

2 participants