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

Possible changes to make dev branch docs more user friendly #247

Open
BethanyRS opened this issue Nov 21, 2022 · 2 comments
Open

Possible changes to make dev branch docs more user friendly #247

BethanyRS opened this issue Nov 21, 2022 · 2 comments
Milestone

Comments

@BethanyRS
Copy link
Contributor

BethanyRS commented Nov 21, 2022

Instead of creating a bunch of minor issues, I thought that it may be better to group some of my more nitpicky suggestions for the docs here. If I missed or misunderstood some documentation, please let me know.

  • \pahfit\pahfit\docs\file_formats.rst mentioned power as an input for "line" and "dust_feature", but I don't see anything for power in the yaml files. It might be worth clarifying that the default yaml file doesn't use it.
  • We still have ipac tables in the \pahfit\pahfit\packs\science folder. Should they still be there? I don't think that the docs explains their presence to new users\that they should avoid using them in the dev branch (?)
  • This isn't specifically related to PAHFIT, so you may not wish to include it. However, as someone who mainly uses conda to manage packages (and who still has a lot to learn about managing packages/environments), I'm not sure how best to handle installations using pip. Should pahfit\pahfit\docs\install.rst have any warnings/tips for conda users?
  • Would it be useful to have some documentation page that keeps track of the main purpose of each .py file, and briefly explains how they tie into each other? While trying to follow the code, I sometime find it hard to figure out how the different files tie into each other/where a function is located. Having a page that gives an overview of the code (or even just lists the names of all the methods/functions of each file in point form) may make it easer for new contributors to get started. It would also make locating methods/functions easier when debugging/updating.
@BethanyRS BethanyRS changed the title Possible nitpicky changes to make dev branch docs more user friendly Possible changes to make dev branch docs more user friendly Nov 21, 2022
@jdtsmith jdtsmith added this to the v2.5 milestone Dec 14, 2022
@jdtsmith
Copy link
Contributor

These are all good thoughts. I think it makes sense to get the dev branch in, work with the example notebooks, and then build out the docs.

@drvdputt
Copy link

Based on questions in #254 , we should really have an explicit explanation of how to use fwhm fitting instead of instrument pack values. I don't think it's intuitive to the user at the moment that no bounds == fixed, or give bounds == fit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants