Merge pull request #120 from pulibrary/new_practices

Add new DLS practices

Gemfile.lock

@@ -94,7 +94,7 @@ GEM
       google-protobuf (>= 3.25, < 5.0)
     sass-embedded (1.72.0-x86_64-darwin)
       google-protobuf (>= 3.25, < 5.0)
-    sass-embedded (1.72.0-x86_64-linux-gnu)
+    sass-embedded (1.72.0-x86_64-linux)
       google-protobuf (>= 3.25, < 5.0)
     terminal-table (3.0.2)
       unicode-display_width (>= 1.1.1, < 3)
@@ -123,4 +123,4 @@ DEPENDENCIES
   webrick
 
 BUNDLED WITH
-   2.2.16
+   2.4.10

development_practice.md

@@ -2,10 +2,8 @@
 
 ## Selecting an issue
 
-Each week we either work from the [Work Cycle
-Board](https://app.zenhub.com/workspaces/dls-work-cycle-613924a1df719e0013b678b0/board?repos=98223070)
-or the [Maintenance & Research
-board](https://app.zenhub.com/workspaces/dls-maintenance--research-6139264d4f68940016d4b7cf/board?repos=26446857,98223070,49439415,157741631,251438007).
+We work from the [Work Cycle
+Board](https://app.zenhub.com/workspaces/dls-work-cycle-613924a1df719e0013b678b0/board?repos=98223070).
 
 We also have a [Learning-friendly Board](https://app.zenhub.com/workspaces/dls-learning-friendly-62e046ab829aafbe2d6520b2/board) for members of our team who are focused on training and not working on work cycle issues.
 

issues.md

@@ -27,25 +27,21 @@ If a "sudden priority" issue comes up, a product owner should do the following:
 1. Create the Github issue. Include as much information as possible.
 1. Add a "Sudden Priority" justification section. This should include how
    staff's work is being impacted and why there are no suitable workarounds.
-   Please also include how urgent the priority is - can it wait until a couple
-   weeks until the next maintenance week, or must it be done immediately?
+   Please also include how urgent the priority is - can it wait a couple
+   weeks until the next planning meeting, or must it be done immediately?
 1. Add the "sudden-priority" label to the issue.
 1. Send a message in Slack to the "digital_library" channel so DLS knows to
    begin acting on the issue.
 
 DLS should then do the following:
 
 1. Ensure the issue is actionable.
-1. Give the issue a "work-cycle" or "maintenance/research" label depending on
-   which week in the work cycle is (or maintenance/research if the issue can be
-   delayed until then), and pin it in Zenhub. Move it to the "Ready"
-   column for that week.
+1. Give the issue a "work-cycle" label. If it needs to be done ASAP, ping DLS in #digital_library and the DLS Lead will work with you to get it prioritized before the next planning meeting.
 
 The DLS Lead reserves the right to remove the sudden-priority label if they make
-a call that the issue is best delayed until the next project work cycle or a
-regularly scheduled maintenance/research week. If they
+a call that the issue is best delayed until the next project work cycle. If they
 do so, the issue will be marked as "on-deck" and pinned in the work cycle
-planning or maintenance board, as appropriate.
+planning board.
 
 Example of a sudden priority issue:
 [figgy/4811](https://github.com/pulibrary/figgy/issues/4811)

work_cycles.md

@@ -7,34 +7,34 @@ title: Development Work Cycles
 ## Development Rhythm
 
 Our team works in a 3 week rhythm. Work cycles are two-weeks long, and every third
-week is a maintenance/research week.
+week is a planning and spin-down week.
+
+The goal of planning and spin-down week is to recognize the time it takes to strategically identify and specify tickets, give us a chance to have more strategic meetings, and work on research that might be hard to fit in at other times.
 
 The following table represents our cycle-related meeting schedule. Each meeting
 will be described below.
 
 |                        | Monday         | Tuesday        | Wednesday | Thursday | Friday  |
 | ---------------------- | -------------- | -------        | --------- | -------- | ------- |
-| Research & Maintenance | Wrap-up        | Cycle Planning | Standup   | Standup  | Standup |
+| Planning & Spin-Down   | Wrap-up        | Cycle Planning | Standup   | Standup  | Standup |
 | Work Cycle (Week 1)    | Standup        | Standup        | Standup   | Standup  | Standup |
 | Work Cycle (Week 2)    | Standup        | Standup        | Standup   | Standup  | Standup |
 
 ## Meetings
 
 ### Work Cycle Planning
 
-Occurs Tuesday at 3:00 PM eastern of Research & Maintenance week. Participants are
+Occurs Tuesday at 3:00 PM eastern of Planning & Spin-Down week. Participants are
 members of DLS and the product owner for the upcoming project.
 
 #### Goals
 
 1. Review the [Work Cycle Board](https://app.zenhub.com/workspaces/dls-work-cycle-613924a1df719e0013b678b0/board?repos=98223070)
     and determine the tickets which will be undertaken in the
-    next two weeks. Give them the 'work-cycle' label.
+    next two weeks. Give them the 'work-cycle' label, ensure they're [well specified](./issues), and move them to Ready.
 1. If this is a feature sprint, PO will identify one ticket which is a
    meaningful enhancement to an existing feature for users. Give it the
    work-cycle label.
-1. Determine if there's any research to be done to validate that the work can
-   happen in the following two weeks.
 
 **Work Cycle Board**:
 [Zenhub](https://app.zenhub.com/workspaces/dls-work-cycle-613924a1df719e0013b678b0/board?repos=98223070)
@@ -49,8 +49,6 @@ Wrap-up meeting. Participants are members of DLS.
 1. Determine if anyone's work is blocked.
 1. Connect with the team.
 1. Find pairing opportunities for the next work day.
-1. If it's a friday, determine a runner for the following week.
-
 
 ### Work Cycle Wrap-up
 
@@ -66,16 +64,23 @@ Fridays for vacation.
    happen.
 1. Share a demo if necessary, but the assumption is that product owners have
    been testing features as they've been implemented.
-1. Review the [Maintenance & Research board](https://app.zenhub.com/workspaces/dls-maintenance--research-6139264d4f68940016d4b7cf/board?repos=26446857,98223070,49439415,157741631,251438007)
-   * Look at the inbox to ensure any newly created maintenance tickets from
-   running or reports are well understood.
-   * Ensure everyone has tasks they can work on in the following week. New maintenance or research tickets should be assigned the "maintenance / research" label so they appear on our maintenance board.
+1. Review the [Work Cycle Board](https://app.zenhub.com/workspaces/dls-work-cycle-613924a1df719e0013b678b0/board?repos=98223070)
+   * Specify any [sudden priorities](./issues) that have been defined and move them to Ready
+
+### Honeybadger Stampede
 
-**Research & Maintenance Board**:
-[Zenhub](https://app.zenhub.com/workspaces/dls-maintenance--research-6139264d4f68940016d4b7cf/board?repos=26446857,98223070,49439415,157741631,251438007)
+Occurs weekly every Tuesday from 3:30 PM to 4:00 PM. Participants are members of DLS.
+
+#### Goals
+
+1. Improve the stability of our software and our ability to react to exceptions as a team in a low-stress ensemble environment.
+1. Browse Honeybadger exceptions that have occurred in the last week.
+1. Ticket any exceptions that should have notified us via monitoring instead of Honeybadger - e.g. Postgres is down.
+1. Look together at any exceptions that are unexpected or may point to us needing to do work - ticket those.
 
 ## Retrospectives
 
 DLS holds regular retrospectives to reflect on our accomplishments and
 challenges, and to discuss any changes we may want to make to team process.
 Retrospectives are scheduled every 6-8 weeks.
+