Merge branch 'main' into dependabot/npm_and_yarn/cypress-on-fix-1.1.0

.github/workflows/cypress-mysite.yml

@@ -18,7 +18,7 @@ jobs:
           uses: actions/[email protected]
 
         - name: Setup Node.js environment
-          uses: actions/setup-node@v4.1.0
+          uses: actions/setup-node@v4.2.0
           with:
             node-version: 'latest'     
 

.github/workflows/lambdaTest.yml

@@ -11,7 +11,7 @@ jobs:
           uses: actions/[email protected]
 
         - name: Setup Node.js environment
-          uses: actions/setup-node@v4.1.0
+          uses: actions/setup-node@v4.2.0
           with:
             node-version: 'latest'     
 

.github/workflows/orange.yml

@@ -11,7 +11,7 @@ jobs:
           uses: actions/[email protected]
 
         - name: Setup Node.js environment
-          uses: actions/setup-node@v4.1.0
+          uses: actions/setup-node@v4.2.0
           with:
             node-version: 'latest'    
 

.github/workflows/playwright-mysite.yml

@@ -66,7 +66,7 @@ jobs:
           run: npm ci
 
         - name: Setup Node.js environment with most recent version
-          uses: actions/setup-node@v4.1.0
+          uses: actions/setup-node@v4.2.0
           with:
             node-version: 'latest'
 

.github/workflows/sauce.yml

@@ -15,7 +15,7 @@ jobs:
           uses: actions/[email protected]
 
         - name: Setup Node.js environment
-          uses: actions/setup-node@v4.1.0
+          uses: actions/setup-node@v4.2.0
           with:
             node-version: 'latest'     
 

html/work-style.htm

@@ -96,19 +96,19 @@
             <br>
             with vague or evolving requirements. I don't need everything spelled
             <br>
-            out for me or much handholding. I appreciate the freedom of more
+            out for me or much handholding. I actually like when things aren't
             <br>
-            flexible environments that allow for initiative and autonomy, while
+            always perfectly defined. It gives me the freedom to think critically
             <br>
-            still staying aligned with broader team goals and deliverables. I trust
+            and solve problems on my own. When there's ambiguity, I see it as a
             <br>
-            my judgment and experience to guide me when things aren't perfectly
+            chance to get creative and take initiative. It's not something I try
             <br>
-            laid out and enjoy the challenge of navigating ambiguity. If something
+            to avoid. It's more like an opportunity to trust my judgment, explore
             <br>
-            doesn't feel right, I'll ask for clarification, but I'm comfortable with
+            different solutions, and figure out the best way forward, even if the
             <br>
-            taking the initiative to find solutions independently.
+            path isn't totally clear. I find that kind of flexibility pretty rewarding.
             <br>
             <br>
             <span class="orangeFont"><b>My Ideal Work Environment</b></span>
@@ -123,9 +123,9 @@
             <br>
             them into requirements. I actually prefer getting involved sooner. It
             <br>
-            helps catch potential issues before they become bigger,
+            helps catch potential issues before they become bigger, time-consuming
             <br>
-            time-consuming adjustments later on.
+            adjustments later on.
             <br>
             <br>
             <strong>Scrum</strong> feels like a more prescriptive way of doing Agile, with its
@@ -164,14 +164,16 @@
             <br>
             <strong>"Light Scrum"</strong>, and it worked fairly well. There were no strict deadlines,
             <br>
-            no story points, and the devs and I weren't tied to the estimates we made
+            no story points, and the devs and I weren't shackled to the estimates we
             <br>
-            during sprint planning. It was more collaborative and less about chasing
+            made during sprint planning. It was more collaborative and less about
             <br>
-            numbers or rigid deadlines.
+            chasing numbers or rigid deadlines.
             <br>
             <br>
-            <span class="orangeFont" id="agile-scrum-anti-patterns">Agile/Scrum Anti-Patterns</span> ❌
+            <span class="sections" id="agile-scrum-anti-patterns">Agile/Scrum Anti-Patterns</span> ❌
+            <br>
+            <span class="orangeFont">Story points = hours?</span>
             <br>
             Tying story points to hours is an anti-pattern. Story points are meant to
             <br>
@@ -193,6 +195,8 @@
             can vary.
             <br>
             <br>
+            <span class="orangeFont">We'll ask for estimates then treat them as deadlines</span>
+            <br>
             Another pitfall is treating estimates like commitments. Estimates are just
             <br>
             guesses based on what we know at the time, and they're often wrong. Yet,
@@ -202,15 +206,17 @@
             commitment.
             <br>
             <br>
+            <span class="orangeFont">Assuming cleaning the kitchen is always half the effort of cooking dinner</span>
+            <br>
             I've experienced a situation where QA points were determined as half of
             <br>
             dev points, which can oversimplify the complexity of testing and didn't
             <br>
-            reflect the true effort involved. It's like assuming cleaning the kitchen
+            reflect the true effort involved.
             <br>
-            is always half the effort of cooking dinner.
             <br>
-            <br>            
+            <span class="orangeFont">The story point trap</span>
+            <br>         
             When story points are treated like a timecard or a strict work quota, it
             <br>
             leads to micromanagement and puts too much emphasis on output