add discussion notes from Gonsiorowski group

Collegeville · Jul 24, 2020 · b548fdb · b548fdb
1 parent 3a72d4c
commit b548fdb
Show file tree

Hide file tree

Showing 2 changed files with 105 additions and 0 deletions.
diff --git a/WorkshopResources/WorkshopSlidesNotes/WorkshopSlidesNotesList.md b/WorkshopResources/WorkshopSlidesNotes/WorkshopSlidesNotesList.md
@@ -13,6 +13,7 @@
 - [Gunter Group Day 1 Discussion](https://docs.google.com/document/d/1c2oxpv4O48CKizpOLk50Ayla16wt36kT2zs244FwoM0/edit?usp=sharing)
 - [Knepper Group Day 1 Discussion](https://docs.google.com/document/d/1Id7rR-pISlUfSCp83-lX16SmoeC7ehB7xh2Ou7QxeGA/edit?usp=sharing)
 - [Milewicz Group Day 1 Discussion](https://docs.google.com/document/d/1TJKT71jVb5_HpCndN-V6HNBBP5JqxG6ckZMW3BQD4Cc/edit?usp=sharing)
+- [Gonsiorowski Group Day 1 Discussion](./gonsiorowski-discussion-day-1.md)
 
 ### Day 2
 - [Atkins Group Day 2 Discussion](https://docs.google.com/document/d/1WZaxIGasM8aeyoE7KyXDjtGsxtYMuqlCKzfLncd2R2o/edit?usp=sharing)

diff --git a/WorkshopResources/WorkshopSlidesNotes/gonsiorowski-discussion-day-1.md b/WorkshopResources/WorkshopSlidesNotes/gonsiorowski-discussion-day-1.md
@@ -0,0 +1,104 @@
+# 2020-07-21 Collegeville Day 1 Breakout Discussion
+
+## Participants
+
+-   Elsa Gonsiorowski, LLNL
+-   Mark Miller, LLNL
+-   Machael Garland, nVidia
+-   Jared O'Neal, ANL
+-   Wyatt Spear, U of OR
+-   Hal Finkel, ANL
+
+## Short-term vs long-term productivity
+
+-   good to have some people focused on each aspect
+-   short-term results, while important, you need to keep an eye out for the long term.
+
+## Productivity intersection with utility?
+
+-   productivity: how much effort does it take to achieve your goal?
+    -   goals are always evolving, each person has different goals
+    -   problem comes when goals are in conflict
+
+## how can you tell if productivity is improving over time?
+
+-   hard to normalize wrt to different goals
+-   how do individuals measure productivity?
+    -   is self assessment (without quantification) enough?
+-   frustration / emotional state is a big indicator about productivity
+
+## what if the work you do one week is 'trown away' the next week?
+
+-   teams need to learn from the macro failure of 'wasted' effort
+-   as long as an individual learns during the process, maybe
+-   Is the "wasted" work the only way you could have reached the conclusion that this was the wrong approach?
+    -   how can we reduce the "wasted" effort next time around?
+-   is there a de-brief that not only looks at what lead to the failure, but then *communicates* this to others
+
+## individual productivity vs management-level productivity
+
+## Efficiency == quality? or just getting-things-done?
+
+-   you know it when you see it
+-   inefficient -> duplication of effort
+-   matching individual skills to the right problems
+    -   resources aligned to the problem
+
+## how to convince an individual to contribute to the wider team?
+
+-   example: how to get the team to write documentation?
+    -   one person would start writing the documentation, then hand it off to a second person to take it over and own it.
+    -   useful to build documentation with other people
+    -   paired programming / paired documentation
+-   interpersonal challenge, both people need to get credit for the end result, both the documenter and the 'original coder'
+-   what are the incentive structures at the management level? can you change those to the get the behavior that you want?
+-   project manager & system engineer roles with opposite incentives.
+    -   project manager: deliver on time
+    -   system engineer: deliver a quality product
+    -   in DOE, these *roles* might be handled by the same person. maybe it should be more explicit, so that people can think clearly about what needs to be done.
+
+## Play to peoples strengths
+
+-   customer interaction vs technical writing
+-   align with what people like to do
+
+## experience: code reviews have lead to some real quality improvements
+
+-   are tools helping you, or getting in the way?
+
+## balance finding the tools that are more useful, but not wanting to learn new things *all* the time
+
+-   wait for the community to reach critical mass on a tool before personally investing in it
+-   good news for tool developers, keep running sessions and getting the word out
+
+## experience: what if management is imposing a tool for everyone?
+
+-   it may depend on the type of tool that management
+-   forced to use a macbook
+-   management can make tools available: atlassian suite, make it easier to use
+    -   need 'fresh blood' people who know whats out there, and can bring it in to the internal work
+
+## q3: what can we make progress in the next year?
+
+-   CI testing
+    -   getting teams used to using that
+    -   making it easier to learn / documentation
+    -   how long can you use the resources?
+    -   which tests exercise the code that was changed?
+    -   and this needs to be automated, not chosen by a human
+-   spack for system administrators
+-   CI with spack does has some technical challenges
+-   tools that are otherwise available, working on HPC systems
+    -   identify where the gap is small, but the benefit would be large
+
+## q4: prerequisites to addressing long-term challenges?
+
+-   recognize the problems
+-   have good community education in place
+-   can we do requirements gathering, before jumping in to technical solutions, esp. if we are solving a problem as a community and each side has their tool to evangelize
+-   requirements gathering is a super import part of the process
+-   common file format? each lab had a different experience, but then had vastly different requirements
+    -   have an objective 3rd party to bring everyone to the table and find the common ground
+    -   3rd party owning the result, not any one lab
+    -   community branding, not just any individual lab
+    -   allow people doing the work the ability to collaborate, without the branding discussion