Hi,
First as my first topic let me say thank you for this amazing framework, You guys did an awesome job. I’m just getting the tip of it but I can see the power within. After those congrats, let me just say that the doc needs a lot more info, there too much info missing. And we have to go inside the files to find information which is really time consuming.
Anyway, here is my questions:
- What is the difference between
boot_session and extend_session hooks?
- And why is there nothing about
boot_session inside Hooks doc? Is it because it’ll be abandoned?
Cheers!
1 Like
I’m not familiar with these hooks. But I can answer your 2nd bullet point:
boot_session appears to be active; there is no mention of it being abandoned.- Here’s a link to the current Frappe code, showing where that key is referenced.
Regarding documentation. This has always been an ERPNext challenge (though in fairness, it’s better than 6 years ago). Because there is no easy solution.
ERPNext is not a traditional, corporate-owned and maintained ERP. Document maintenance does not receive the same priority and emphasis that it would elsewhere. If we (non-maintainers) don’t like the documentation? Well, then we’re lightly encouraged to go make our own improvements (via GitHub Pull Requests).
There are a few problems with that approach.
-
First, we cannot write about topics we don’t understand. For example, you want to read about 'boot_session' and 'extend_session'. Obviously you cannot go fix the documentation until you (somehow) learn how these things work. Or even if they still work.
-
Second, what happens when a developer modifies the code for boot_session and extend_session: how will the documentation be updated?
- Will the developer personally update the docs? If so, how does the developer know which page(s) are related to their modification?
- Will the developer ping you, because you are the most-recent person who wrote documentation about Hooks?
Neither seems probable. More likely, the documentation will become stale/inaccurate. Until someone(s) happen to (1) Notice this, (2) Have the knowledge to fix it, and (3) Choose to fix it.
-
The current approach isn’t sustainable. A handful of random enthusiasts, each slowing updating documentation, cannot match the pace of development. Nor handle major Upgrades by themselves. So for documentation to become truly excellent requires a new approach. We need leaders and champions.
For example, creating an online Working Group, designating leadership, setting goals, and meeting regularly. This hypothetical Group should foster a relationship with Frappe and the other maintainers, to open lines of communication and cooperation.
Ideally, this Group would eventually be granted more ownership of the documentation. So they can make changes without submitting PRs and hoping some random, unknown person decides to approve it. (also, not everything can be achieved via PRs today: for example, you cannot Delete a page)
Worst case, in the unlikely event that cooperation proves too challenging, the Group could maintain their own Unofficial User’s Group documentation website.
But in the meantime, until leaders rise to accept this challenge … we’re stuck in the current status quo:
If we don’t like something, we’re supposed to individually fix it and submit a PR. 