About the callbacks overview section : would you rather have an example of use of the actual callbacks (like LRFinder for example) or, when possible, an example of the built-in function that uses that callback (lr_find in the same example) ?
Also I saw 2 show_doc() functions visible in the actual documentation pages (here’s one just above the linked section). I think they are not supposed to be shown, but I don’t know how to fix it. Do I just mention the instances here ?
then activate the hide_input extension (as shown here). You can point us to them but we’ll likely forget so it’s best if you make a simple PR to fix them.
Hi,
I’d like to help, but am finding it difficult to distill the process I should follow from the various threads on the forum.
I think I need to familiarize myself with the fastai pull request protocol and the contributing to docs process. Can you please confirm?
Thanks
I’m sorry if I’ve missed this somewhere, but:
What is the relationship between the notebooks and the html, for example, between vision.image.ipynb and vision.image.html?
Not sure if related, but there is this sentence in gen_doc_main.html:
“If you want to help us and contribute to the docs, you just have to make modifications to the source notebooks, our scripts will then automatically convert them to HTML.”
But I don’t see a clear relationship between .html and .ipynb files sharing the same file name.
Yes! If you add trainings, maybe make them short (2-3 epochs) so that the notebook doesn’t take too long to run. For 1cycle, you should show the momentums with the LRs since they change as well.
To illustrate the General Scheduler could you point me to a kind of schedule I could implement ? Otherwise I’ll just redo SGD with warm restarts that’s already on the specific page for the General Scheduler but isn’t it a bit repetitive ?
I changed the order of the callbacks to try to be coherent. It would be best if the order in the overview matched the order in the menu “callbacks”, but I don’t know how to change that menu. Any pointers ?
Seems good. Just one note on mixup: I wouldn’t show an example of fit since it doesn’t explain what mixup does. Here giving a general explanation is probably enough.
Thanks for the work!
My PR from yesterday about visible show_doc() doesn’t seem so have an effect on how it looks on the website. That’s weird because for example let’s take this instance (just above the linked section). When I find the corresponding cell in the fastai source it indeed says hide_input = true but that’s not reflected on the doc page, even though it was last generated today.
Here’s the full cell of the example that show hide_input = true:
For better documentation, I think it’d also be a good idea to migrate some of the notes in forums to corresponding fastai docs, often it’s very difficult to find some of those gems in the forums.
So if you stumble upon useful summaries, tips, performance notes, and other useful information that can be extracted/compiled into a stand-alone document or a section of an existing one, that would be a great service to this community.
In general we put normal user docs under fastai’s repo docs/*md, and more of the core dev docs under docs/dev/*md, but don’t worry too much about the proposed placement - it’s easy to reorganize those later.
Reading through some of the posts by @jeremy and @sgugger is probably a good starting point, but there are plenty other wonderful contributions by others hidden in the forums.
I compiled some of the answers in this thread into extra notes in the first post. The first post is now a wiki, so please don’t hesitate to improve it.