Talk:K8s Installation/Process/Ingress

What is the meaning of this task in the context of PKC?

Software task, such as installing technology for a certain goal, is a special kind of task. It is a combination of "to know" and "to do". Although the current software engineering paradigm involves decent methodology to cope with complexity, which manifests in its engineering-oriented language, the cognition issue remains unaddressed.

The meaning of digging into the K8s installation task is to practically apply our mindset(UDA) to an important genre(SWE) of tasks.

The primary challenges emerged from the task

• Opinion: the "cognitive process" of engineering is only indirectly "taken care of"(benefit) by the whole system (tools, methodology, community, paradigm). Generally, the reason why an issue isn't addressed includes that there are alternatives to solve the issue, making solving this issue unnecessary. In this case, we have lots of engineering methodologies which benefit so much so we always talk about engineering itself instead of how we engineer.
• Describing resources, tasks properly
• Deliberation of different kinds of questions.

The aforementioned process is done well in most official documentation but not discussed in a meta level.

How does this task manifests the discipline "eat our own dog food"?

• At the start of this task, I thought it has little difference from other technical tasks -- to dig into command lines, check tons of Stackoverflow and Github pages and solve bugs. Therefore, no documentation was needed at the beginning until I figure out a decent part of the task and am ready for presentation. I record the unstructured data on a random note-taking system, just to jot down everything in my head with less cognitive loading. Besides, writing more structured information on Wiki is the regular cooperation paradigm. However, I found myself unavailable to share the process when I'm still diving into the bugs, which in other words, it requires extra power to organize the process data. The dilemma is whether to spend more time on organizing or comprehension.

Benefits of insert data in the system without structure

• While data is in our head, it isn't consolidated
• The structure will naturally emerge

Drawback of the previous decision (Regular engineering task with regular documentation granularity)

• Viewing the task as a regular engineering task does not solve the underlying <cognition and data issue>.
• The big granularity of documentation makes communication granularity also big. We cannot report status at any preferred time, not to mention the asynchronous communication when the status is checked passively.
• One of the root cause is lack of structure. We don't know which template to fill in when the workflow is not defined (Wikipedia:Capability Maturity Model). Fortunately, the structure-oriented system(PKC) has great potential to speed up the maturity progress. Once the structure is defined, participants of this process have an optimized cognition space, which means less decision and more structure extracted from every piece of data.

Note

• Ben thinks it deviates from our discipline of "eat our own dog food" from a basic level, which contradicts my decision based on this task instance. I pondered the discipline and find out why it still holds in this scenario. Therefore, the discipline has more ground.
• A lot of contradictions come when we do not have a proper argumentation system built on top of it. A root cause is that we cannot properly abstract the related concepts and describe them. This observation can induce that defining terms (naming) is a fundamental cognitive power of a person, a group, or a community.