Add missing pages into structure

18F · Apr 1, 2021 · 2d61ad0 · 2d61ad0
1 parent b60fa09
commit 2d61ad0
Show file tree

Hide file tree

Showing 8 changed files with 24 additions and 8 deletions.
diff --git a/_data/navigation.yml b/_data/navigation.yml
@@ -36,6 +36,10 @@ approach:
     href: /incident-reports/
   - text: Architecture Reviews
     href: /architecture-reviews/
+  - text: Front-End Disciplines
+    href: /frontend/
+  - text: Example Workflows
+    href: /example-workflows
 
 tools:
   - text: Tools

diff --git a/_pages/architecture-reviews/data-act-pilot.md b/_pages/architecture-reviews/data-act-pilot.md
@@ -1,5 +1,7 @@
 ---
 title: 'DATA Act Pilot: Simplicity is Key'
+sidenav: approach
+sticky_sidenav: true
 ---
 
 ## TL;DR

diff --git a/_pages/architecture-reviews/micro-purchase.md b/_pages/architecture-reviews/micro-purchase.md
@@ -1,5 +1,7 @@
 ---
 title: 'Micro-purchase: Do one thing well'
+sidenav: approach
+sticky_sidenav: true
 ---
 
 ## TL;DR

diff --git a/_pages/example-workflows.md b/_pages/example-workflows.md
@@ -1,8 +1,8 @@
 ---
 title: Example Workflows
+sidenav: approach
+sticky_sidenav: true
 ---
-## Example Workflows
-
 Here we've collected descriptions of team processes (particularly around
 submitting code) that various projects have used in the past. Please consider
 using one as an example until a more formal template is provided.

diff --git a/_pages/frontend.md b/_pages/frontend.md
@@ -1,10 +1,8 @@
 ---
 title: Front-End Disciplines
+sidenav: approach
+sticky_sidenav: true
 ---
-## Related topics
-* [CSS]({{site.baseurl}}/css)
-* [JavaScript]({{site.baseurl}}/javascript)
-* [Security]({{site.baseurl}}/security)
 
 ## What is front end?
 
@@ -33,3 +31,8 @@ should feel comfortable developing and implementing client-side
 interactions and frameworks using semantic HTML5 and JavaScript, and
 should be able to help with debugging, testing, and performance
 optimization of the code base.
+
+## Related topics
+* [CSS]({{site.baseurl}}/css)
+* [JavaScript]({{site.baseurl}}/javascript)
+* [Security]({{site.baseurl}}/security)
diff --git a/_pages/incident-reports.md b/_pages/incident-reports.md
@@ -2,6 +2,8 @@
 title: Incident Reports
 sidenav: approach
 sticky_sidenav: true
+redirect_from:
+  /incident-reports/cloud-gov/
 ---
 
 Though we fully expect to write dependable applications, every project will
@@ -50,7 +52,6 @@ Don't make folks search for the information.
 
 ## Examples
 * [C2](./C2/c2-outage-report-2016-08-10.pdf)
-* [Cloud.gov](./cloud-gov)
 
 ## Additional resources
 * John Allspaw's [introduction](https://codeascraft.com/2012/05/22/blameless-postmortems/)

diff --git a/_pages/people/2016-Assessment-Guide.md b/_pages/people/2016-Assessment-Guide.md
@@ -1,5 +1,7 @@
 ---
 title: 18F Engineering 2016 End of Year Assessment Guide
+sidenav: approach
+sticky_sidenav: true
 ---
 
 18F, as a part of GSA, has a mature [performance management and recognition system](https://insite.gsa.gov/portal/content/500278). 

diff --git a/_pages/people/2017-Assessment-Guide.md b/_pages/people/2017-Assessment-Guide.md
@@ -1,5 +1,7 @@
 ---
 title: 18F Engineering 2017 End of Year Assessment Guide
+sidenav: approach
+sticky_sidenav: true
 ---
 
 18F, as a part of GSA, has a mature [performance management and recognition system](https://insite.gsa.gov/topics/hr-pay-and-leave/employee-performance-management). 
@@ -25,7 +27,7 @@ In September 2016, a group of Engineering leadership and engineers met to determ
 The number one desired outcome was actionable feedback for individuals. In order for a review to be valuable, the person being reviewed needs to finish the process with knowledge of and a plan for how to grow over the following year. At the end of the review period, every engineer should have a solid understanding of what to do next to continue to improve and deliver better value to their teams.
 
 ### Fair rating
-Individuals deserve fair ratings. These ratings should be calibrated both within Engineering and across 18F. The ratings and feedback should be aligned with the individual’s performance profile (as is required of course), and not biased towards individuals that the raters have interacted with more than others or those whose strengths align the most with their raters’ interests. Positive and constructive feedback should be balanced, and all feedback should be backed by evidence. Ideally the individual agrees with the rating they’re given.
+Individuals deserve fair ratings. These ratings should be calibrated both within Engineering and across 18F. The ratings and feedback should be aligned with the individual’s performance profile (as is required of course), and not biased towards individuals that the raters have interacted with more than others or those whose strengths align the most with their raters’ interests. Positive and construective feedback should be balanced, and all feedback should be backed by evidence. Ideally the individual agrees with the rating they’re given.
 
 ### Holistic review
 Individuals should be rated not only on their technical abilities and contributions, but on their total contribution to their teams and 18F. 18F Engineering performance plans include critical elements for technical and team contributions, and of course are how folks are rated. This means the reviewers must seek to understand the individual's role on their teams: for example, were they doing any project management or design work in addition to committing code. The reviewer should seek feedback from the individual’s project leads and more experienced technical staff they’ve worked with. Additionally, if an individual has contributed to other areas of 18F through guild and working group contributions, the reviewer should gather feedback from leaders and stakeholders in that group.