[DOC] Add information about how to contribute#307
[DOC] Add information about how to contribute#307lionelkusch wants to merge 85 commits intomind-inria:mainfrom
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #307 +/- ##
=======================================
Coverage 98.08% 98.08%
=======================================
Files 22 22
Lines 1148 1148
=======================================
Hits 1126 1126
Misses 22 22 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
docs/src/index.rst
Outdated
| dev/CONTRIBUTING | ||
| dev/index | ||
| generated/gallery/examples/index |
There was a problem hiding this comment.
| dev/CONTRIBUTING | |
| dev/index | |
| generated/gallery/examples/index | |
| generated/gallery/examples/index | |
| dev/CONTRIBUTING | |
| dev/index |
Not 100% sure this is the place to modify it but it would be preferable if the navigation bar displays: API | examples | contributing / more (dropdown menu)
There was a problem hiding this comment.
Yes, it's the right place for the modification of the position of the head navigation page.
The drop menu is defined by the number of elements to show need to be modified in the configuration file.
I updated it and told me if it's what you expected.
There was a problem hiding this comment.
Yes, sorry if I did not express myself clearly. The point was to have API and exemples as the two first elements.
I let you decide the number of elements before dropdown.
There was a problem hiding this comment.
I also suggest to add the install before the API.
There was a problem hiding this comment.
The installation is on the main page.
I don't see the point to add it to the header navigator.
For going more in this direction, I was including Quick start for contributing but @bthirion seems not happy with it.
bthirion
left a comment
There was a problem hiding this comment.
Looking at the result, I find that the contributors page is just a bunch of links toward other pages. I don't really like it, because it requires readers to click again and again. I'd rather have the information concentrated on few, dense pages.
|
For instance, one big page for |
Co-authored-by: bthirion <bertrand.thirion@inria.fr>
What is the page "contributors page"?
Do you want to merge For the structure of the development documentation, I don't know what is the best way to organise the developer documentation. |
bthirion
left a comment
There was a problem hiding this comment.
I ahve a bunch of minro comments. LGTM overall.
| - A **summary of the expected result**. | ||
| - Any **additional details** where the bug might occur or doesn't occur unexpectedly. | ||
| - A **code snippet** that reproduces the issue, if applicable. | ||
| - **Version information** for Python, HiDimStat, and relevant dependencies (e.g., scikit-learn, numpy, pandas). |
There was a problem hiding this comment.
Isn't there a simple command to get this information ? Otherwise people won't do it properly (or won't do it at all).
There was a problem hiding this comment.
It will depend on the package manager, but in your case, pip list should be enough.
I add a line for indicated it.
There was a problem hiding this comment.
I can create a GitHub template for helping the user to create issues.
Co-authored-by: bthirion <bertrand.thirion@inria.fr>
| each file. | ||
|
|
||
| .. ADD THIS SECTION WHEN THERE WILL BE DOCSTRING TESTS | ||
| ``` (I don't think there will be any in a near future) |
There was a problem hiding this comment.
I want to include some tests related to the figure generated in the examples.
For it's important because the change in the figures can imply a change in the text of the examples.
I open an issue regard to it #312 .
@jpaillard @bthirion From my side, I don't like to have a unique page but if you tell me that it is best, I do it. |
|
The current solution where the |
|
I agree that the narrative documentation is more important. For your other packages, I think that the library was developed by the users of it, in case it's more natural to define create the narrative documentation at first . In my case, I don't use it and mainly develop it; it's more natural for me to create the developer’s documentation at first. As I mentioned in issue #306, it's really difficult for me to create this type of documentation. I will need a real practical case for starting it. The only solution that I find for the moment is to organise a workshop on this topic. |
Yes, that's the right way to proceed. |
This is based on the PR #304 and #301.
I added some files for improving the documentation based on Contribution files from different projects: