- Mailing Lists
- Contributors
- Re: Discover the OCA priorities for 2021 proposed by the board
Archives
- By thread 1419
-
By date
- August 2019 59
- September 2019 118
- October 2019 165
- November 2019 97
- December 2019 35
- January 2020 58
- February 2020 204
- March 2020 121
- April 2020 172
- May 2020 50
- June 2020 158
- July 2020 85
- August 2020 94
- September 2020 193
- October 2020 277
- November 2020 100
- December 2020 159
- January 2021 38
- February 2021 87
- March 2021 146
- April 2021 73
- May 2021 90
- June 2021 86
- July 2021 123
- August 2021 50
- September 2021 68
- October 2021 66
- November 2021 74
- December 2021 75
- January 2022 98
- February 2022 77
- March 2022 68
- April 2022 31
- May 2022 59
- June 2022 87
- July 2022 141
- August 2022 38
- September 2022 73
- October 2022 152
- November 2022 39
- December 2022 50
- January 2023 93
- February 2023 49
- March 2023 106
- April 2023 47
- May 2023 69
- June 2023 92
- July 2023 64
- August 2023 103
- September 2023 91
- October 2023 101
- November 2023 94
- December 2023 46
- January 2024 75
- February 2024 79
- March 2024 104
- April 2024 63
- May 2024 40
- June 2024 160
- July 2024 80
- August 2024 70
- September 2024 62
- October 2024 121
- November 2024 117
- December 2024 89
- January 2025 59
- February 2025 104
- March 2025 96
- April 2025 107
- May 2025 52
- June 2025 72
- July 2025 60
- August 2025 81
- September 2025 124
- October 2025 63
- November 2025 22
Contributors
Re: Discover the OCA priorities for 2021 proposed by the board
I don't know but I feel like any standard solution won't work for us.
In a normal software project, you just have 1 branch (maybe 2: devel/stable). Then you add sphinx/mkdocs on a separate folder and docs live happily with your source code. Besides, those tools analyze your docstrings and autogenerate docs. Each repo contains 1 package, which has a single evolving version that follows a standard schema such as PEP 400, semver, calver, etc.
OCA has a workflow that is very alien to general github workflow:
- Code is spread across different repos.
- Each repo has different modules which can be tightly or loosely related among themselves and among modules that might exist in other repos.
- Each module has its own version. Which, BTW, means nothing in reality and follows a different schema imposed by Odoo and some OCA members.
- Each repo has multiple maintained versions of each module, one (or zero) per branch.
I think this is a deeply rooted problem across the whole OCA that hinders contributions and makes any move hard to achieve. I've tried to fix that in the past without success, so I don't care anymore. It's the OCA we have and I have to accept that.
So, having all that said, I think that the only way this could work is stick as it is: one README per module/version pair.
Odoo docs situation is today less crazy, so in case we have some functional stuff to document, if possible, the place to do it would be https://github.com/odoo/documentation
IMHO user docs should be avoided and, instead, modules should be self-explained within the UI. That goes through having friendly empty pages, tours, help tooltips, self-explained dialogs, res.config.settings dialogs, etc. Just make the module obvious and save documentation.
For other kind of cross-module, cross-repo, deployment, etc, kind of docs, possibly a single mkdocs repo could be deployed. As it wouldn't be coupled with any specific repo, odoo version or module, it wouldn't need any versioning or branching: just one main branch and build on each commit.
by Jairo Llopis - 11:21 - 25 May 2021
Reference
-
Discover the OCA priorities for 2021 proposed by the board
Hello contributors,Here is our latest blog post to present the 2021 OCA priorities proposed by the Board:Don't hesitate to come back to us/me if you'd like to give your feedback!Have a nice day,--
Virginie for the Board
by Virginie Dewulf. - 10:11 - 17 Mar 2021