As our activities shifted toward the GitHub repository, where most of
the discussions are being held, you won't be surprised to find these
minutes quite lean:
The last few days were quite successful in terms of recruitment; yet we
look forward to more contributors ;P
Best wishes for the end of the year and see you soon,
Just probing your energy and availability. I can think of a couple of things to discuss:
- PRs (I am all in favor of Badr's idea, found in the minutes, to now move to a page-centric workflow, and also we clarify a detail or two about external PRs)
- improving the "how to contribute" guidelines with Badr's document, also found in the minutes
- clarify a couple of things about the pending issues, PR and the rest
The reason I am suggesting this week is that Christmas is drawing closer and not just Christians like to take a few days off in that occasion, and it's going to make planning meetings a little bit more difficult.
Let me know!
Present: Ivo, Andres, Mike, Badr, Attila
What we discussed:
On Telegram we discussed the option of using CC BY-SA 4.0, but that brings in a few issues:
- compatibility with GPL (https://creativecommons.org/share-your-work/licensing-considerations/compat…)
- and a smooth transitioning from the previous docs.
We agreed to use the same Licensing the previous team was utilizing: GPL 1.2/1.3.
Based on Adrien's points:
- Labeled external branches.
>As hinted at in the my last commit to the README, I suggest we >adopt a workflow where all PRs are made from new branches >labeled appropriately, as suggested in the "three types of >commits" bullet point on the README. If you have a better way of >labeling let me know, it's just a suggestion to improve the >readability of the git history (I will have to squash my own >commits too so not giving lessons here)."
We agreed to this.
- We probably need to agree on commit message structure as commit messages have to be descriptive.
- Each branch should be one document, each PR should be for that single document.
Badr already started to work on a cheatsheet/guide for git already where we could include the workflow too: https://badarotti.github.io/openSUSE-docs-revamped/contributing/
- Adjusting presentation:
>I am still trying to figure out a good model for presenting >documentation differently depending on the audience, TW vs Leap, >"give me the list of steps" vs "explain more", as described >here: https://github.com/openSUSE/openSUSE-docs->revamped/issues/11#issuecomment-739492149. For me it's the main >blocker as of now, in the sense that it's preventing me from >diving into writing this or that article I had ideas for. If you >could make progress on this that would be huge. A linked >question is whether we should use versioning for this, somehow.
Seems that Badr done the heavy lifting for us already (special thanks for this awesome work): https://badarotti.github.io/openSUSE-docs-revamped/distribution/
The strucutre covers both Leap and TW as the installation is not that different from each other.
The install section is more a step-by-step guide
Section 1-2 - "Pre-install" and "Install"- is to get you up and running ASAP.
"After install Setup" and "Advanced topics": deep dive, advanced docs << "Explain more" sections
Recommended setups: config based on a user profiles, generic recommendations as per the user requirements.
"Advanced topics": more details can be added here on oS infra and software.
Main focus on Leap and TW as needed.
Versioning to follow the exact versioning of Leap and TW should have no versioning. When there is a Leap version bump we branch it and change the version number. For reference how versioning for different releases could look like:
Also Badr suggested a different approach to PRs: everybody adopt a page, works on it and discuss under the issues the changes and make a PR if agreed on and applied discussed changes if any. We should consider this at least during the early stages of the project, TBD.
Speaking of versioning, added `mkdocs versioning` at https://github.com/openSUSE/openSUSE-docs-revamped/tree/web-functions-versi…. Careful this one is both a python module of its own and an mkdocs plugin. Needs *installing* before building.
The plugin option has been accepted.
- Rolling vs. stable description:
Must read the way Badr explains the difference between Leap and TW - stable vs. rolling - and we need to have a discussion on this.