Closed singularityhacker closed 4 years ago
The issues above are separate.
"Our Course Steward Model Each Scrum.org course is assigned 2 stewards. The stewards are ultimately responsible for collecting input on the course materials, both those that exist and potentially additions to be made, review that input with the community along with Ken Schwaber and provide updates as required.
Each course is stored in GitHub, allowing version control, feedback mechanisms, distribution and much more, not unlike the code that Scrum Teams deliver for their products. Through GitHub capabilities, a PST can submit feedback on a course materials, its delivery content, speaker notes, exercises and much more. With PSTs around the world teaching the materials, that provides a fantastic number of people to provide excellent feedback to improve the content and quality of the courseware. Learn more about the PSM II class from one of our course stewards Barry Overeem and fellow Professional Scrum Trainer Joshua Partogi." - https://www.scrum.org/courses/professional-scrum-master-ii-training
If writing in git is largely about getting to the source of things then it makes sense to get to the source of things in tooling as well. This has been a rocky patch since taking on this experiment. A few things to take into mind:
So I'v settled into using VS Code for my writing tool.
Content/code is a continuum, not binary. Code should be self-documenting and content should be precise enough to be formally modeled to some extent.
Grammarly removed from the market place. Use the package directly: https://github.com/znck/grammarly/releases/tag/v0.12.2
VS Code crash course:
On the idea that code/content as a continuum:
See the triangle: diagram/content/code
Not suggesting a curry-Howard correspondence but a meaningful continuum.
We are made for image recognition. The memory master leverage cognitive cathedrals to retain large amounts of information. Even some programming languages are introducing this correspondence: https://ballerina.io/
Content as "wet code" and code as "dry code": http://unenumerated.blogspot.com/2006/11/wet-code-and-dry.html
Some notes on recent pattern changes and advances:
Chrome extension to market with this next blog post series:
Aligning ideas:
Commits vs work count. Measure the right thing. https://github.com/marketplace/actions/word-count
Questions I said I would address in my previous post:
Read the tutorial for anything I may have missed: https://www.scrygroup.com/tutorial/2020-01-07/guide-to-git-github-for-writers/
My last post for reference: https://medium.com/@justiceconder/writing-on-github-c35ddd12bfd8
Tips:
Follow up to "Github for Writing"
https://about.gitlab.com/blog/2018/03/05/gitlab-for-agile-software-development/
Replaces:
Maybe all project management should be managed through version control. The Org will be swallowed by code and in doing so, it will be swallowed by source control.
See for mapping traditional agile concepts to git entities: