-
Notifications
You must be signed in to change notification settings - Fork 51
Further refactoring of tools.md #333
Copy link
Copy link
Open
Description
A lot of good suggestions, and I wish all of these were in separate comments so it could have been easily voted upon. It's not, so here are my 2 cents
yes
- reorganize the "tools" section using tabs (one tab per programming language/ecosystem should work fine here, to keep the attitude "user-centered")
- importance of the search feature
- make list much shorter
- I really like what they did here for data formats, summarizing everything in a table. https://aaltoscicomp.github.io/python-for-scicomp/work-with-data/#what-to-look-for-in-a-file-format . Perhaps that is a solution?
unclear, but maybe
In code documentation is discussed anyway in the following episode. This could be moved ahead of this one?
- I guess you mean to move in-code section to the end? Maybe. Human readable prose-like docs should wrap around docs generated from in-code docs.
- One can also argue that parsing in-code docs is a feature of certain tools. And it follows different conventions / styles. If so the order should be markup formats, readme etc, in-code docs, tools and that I can buy.
notebooks/literate programming as a category.
- sure, as another format, as long as we don't repeat the Jupyter lesson and not lengthen the course, which we don't want do we?
Originally posted by @ashwinvis in #310
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels