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 module #140

Merged
merged 6 commits into from
Oct 2, 2024
Merged

Documentation module #140

merged 6 commits into from
Oct 2, 2024

Conversation

DaniBodor
Copy link
Contributor

No description provided.

@DaniBodor DaniBodor changed the title Documentation module dbodor Documentation module Oct 1, 2024
Copy link
Collaborator

@JaroCamphuijsen JaroCamphuijsen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left some comments, but I actually approve of all your changes. I just think we could better structure and distinguish the different types/implementations/formats, which are currently all called "type" in this module. But this is something for a future PR.

- Tutorial(s)
- In-code documentation
- API reference
- Overview of components
- User documentation
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DaniBodor these three types of documentation that were mentioned here, are more or less three high level categories of documentation divided by the audience. The things you added seem to me to be a collection of 1) different formats/implementations of documentation [README, in-code docs, API ref/docstrings (could also add a web page to this list and a printed paper/book] and 2) a shape/narrative type [tutorial, overview of components, story/narrative]. I think it might be confusing to put them all in one list, but I do like the idea of looking at these different aspects of audience/implementation/shape. For example, you could have a tutorial that describes how to deploy the software written down in a README file, or you could have an overview of components and descriptions on how to use them written down in comments in the code (not the best user documentation, I agree). What do you think about this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had put different "levels" of documentation into this list on purpose. Apart from the three high level ones, all the others are also part of the previous exercise as well as part of the "types of documentation" tab, so there should be plenty of info around.
I see how it could be confusing, but in my mind not so much so that it is preventative. I'm happy to change it though, if you disagree.

modules/documentation/slides_documentation.md Outdated Show resolved Hide resolved
@JaroCamphuijsen JaroCamphuijsen merged commit fcaf31b into main Oct 2, 2024
1 check passed
@DaniBodor DaniBodor deleted the documentation-module-dbodor branch October 2, 2024 07:28
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

Successfully merging this pull request may close these issues.

2 participants