50 change management and git - #74
Draft
aassuied-ps wants to merge 15 commits into
Draft
Conversation
Add an introduction and a plan.
talk about tools
Collaborator
|
@aassuied-ps I added some content in the suggestions, thanks for starting this! |
frostwix
reviewed
Jul 1, 2026
frostwix
left a comment
frostwix
left a comment
Contributor
There was a problem hiding this comment.
Only reviewed first two sections so far
|
|
||
| The Change Curve is a well known model for understanding how employees resond to change @HOLDSWORTH2024254. While there are many different implementations of it, generally speaking it is understood to be split into two main phases, first of resistance and then of acceptance. An important attitude in any company trying to make any sort of change, be it organisational or technological, is to have empathy for those individuals who are experiencing it, and give them the support they need. | ||
|
|
||
| We must understand that any change will take time to embed into an organisation, and the main thing we can influence is how fast that change goes, and how well we can adopt the technology. |
Contributor
There was a problem hiding this comment.
"and how well we can adopt the technology"--what does this mean?
Collaborator
There was a problem hiding this comment.
I have reworded this, see what you think!
Co-authored-by: frostwix <154441859+frostwix@users.noreply.github.com>
Co-authored-by: frostwix <154441859+frostwix@users.noreply.github.com>
Co-authored-by: frostwix <154441859+frostwix@users.noreply.github.com>
Co-authored-by: frostwix <154441859+frostwix@users.noreply.github.com>
Co-authored-by: frostwix <154441859+frostwix@users.noreply.github.com>
Co-authored-by: frostwix <154441859+frostwix@users.noreply.github.com>
frostwix
reviewed
Jul 17, 2026
|
|
||
| ## The Change Curve | ||
|
|
||
| The Change Curve is a well known model for understanding how employees respond to change @HOLDSWORTH2024254. While it has many different forms, it generally begins with initial shock, followed by resistance, low morale, gradual experimentation, and then acceptance and integration. An important consideration for any company trying to make any significant change, be it organisational or technological, is to have empathy for those individuals who are experiencing it and give them the support they need. |
Contributor
There was a problem hiding this comment.
I imagine we don't want this "@"
Suggested change
| The Change Curve is a well known model for understanding how employees respond to change @HOLDSWORTH2024254. While it has many different forms, it generally begins with initial shock, followed by resistance, low morale, gradual experimentation, and then acceptance and integration. An important consideration for any company trying to make any significant change, be it organisational or technological, is to have empathy for those individuals who are experiencing it and give them the support they need. | |
| The Change Curve is a well known model for understanding how employees respond to change. While it has many different forms, it generally begins with initial shock, followed by resistance, low morale, gradual experimentation, and then acceptance and integration. An important consideration for any company trying to make any significant change, be it organisational or technological, is to have empathy for those individuals who are experiencing it and give them the support they need. |
frostwix
reviewed
Jul 17, 2026
|
|
||
| Depending on your company's size and how they want to use Git, there a number of tools to interact with Git and Github. These are covered more in the [appendix](tools.qmd), but your decision is likely to be motivated based on how close you want users to interact with Git. | ||
|
|
||
| You may decide that you wish to abstract users access to Git or you might decide that you wish to get users comfortable with direct Git terminal access. Different tools will enable different approaches. |
Contributor
There was a problem hiding this comment.
Is this in line with the intention of this sentence?
Suggested change
| You may decide that you wish to abstract users access to Git or you might decide that you wish to get users comfortable with direct Git terminal access. Different tools will enable different approaches. | |
| You may choose to hide Git's complexity from users by giving them easy-to-use tools, or you may choose to teach users to work directly with Git commands in the terminal. The tools you select will influence which approach is possible. |
|
|
||
| There are a number of excellent resources for learning Git online. This means that when creating internal documentation on Git it is important to focus on how your organisation will be using Git in practice. | ||
|
|
||
| Your documentation should focus first on the ways someone will work in their day to day, covering the typical flow and where possible integrating it into the tools they are likely to use. Documentation should be easy to access and use, and easy to search. We recommend where possible to not include this level of documentation in GxP training, as the latter is likely to be in systems that can be harder to update quickly based on user feedback. |
Contributor
There was a problem hiding this comment.
Suggested change
| Your documentation should focus first on the ways someone will work in their day to day, covering the typical flow and where possible integrating it into the tools they are likely to use. Documentation should be easy to access and use, and easy to search. We recommend where possible to not include this level of documentation in GxP training, as the latter is likely to be in systems that can be harder to update quickly based on user feedback. | |
| Your documentation should focus first on the ways someone will work in their day-to-day, covering the typical flow and where possible integrating it into the tools they are likely to use. Documentation should be easy to access and use, and easy to search. We recommend where possible to not include this level of documentation in GxP training, as the latter is likely to be in systems that can be harder to update quickly based on user feedback. |
|
|
||
| Your documentation should focus first on the ways someone will work in their day to day, covering the typical flow and where possible integrating it into the tools they are likely to use. Documentation should be easy to access and use, and easy to search. We recommend where possible to not include this level of documentation in GxP training, as the latter is likely to be in systems that can be harder to update quickly based on user feedback. | ||
|
|
||
| GxP training is of course important to meet our compliance requirements, but we can normally build training on top of it which enables more dyanmic updates as you get feedback from users on what works and what does not. |
Contributor
There was a problem hiding this comment.
Suggested change
| GxP training is of course important to meet our compliance requirements, but we can normally build training on top of it which enables more dyanmic updates as you get feedback from users on what works and what does not. | |
| GxP training is of course important to meet our compliance requirements, but we can normally build training on top of it which enables more dynamic updates as you get feedback from users on what works and what does not. |
|
|
||
| ### Failure cases | ||
|
|
||
| An important resource to build over time is how to resolve issues that might occur when using Git. The exact nature of the issues are likely to run into will be specific to your organisations workflow but some likely common issues are |
Contributor
There was a problem hiding this comment.
Suggested change
| An important resource to build over time is how to resolve issues that might occur when using Git. The exact nature of the issues are likely to run into will be specific to your organisations workflow but some likely common issues are | |
| An important resource to build over time is how to resolve issues that might occur when using Git. The exact nature of the issues users are likely to run into will be specific to your organisation's workflow but some likely common issues are |
|
|
||
| Where possible trainings should be live, and in person if it is possible to arrange, to allow maximum engagement. | ||
|
|
||
| One vital aspect is that training should be targetted only at individuals who are going to be adopting the Git workflow very soon, or who are already adopting it. This means that what they have learnt can be applied straight away, removing the danger of knowledge atrophying during use. Related to this, if you can train cohorts of users who will be working together, this can be very useful as they will be able to learn and practice together. |
Contributor
There was a problem hiding this comment.
Suggested change
| One vital aspect is that training should be targetted only at individuals who are going to be adopting the Git workflow very soon, or who are already adopting it. This means that what they have learnt can be applied straight away, removing the danger of knowledge atrophying during use. Related to this, if you can train cohorts of users who will be working together, this can be very useful as they will be able to learn and practice together. | |
| One vital aspect is that training should be targetted only at individuals who are going to be adopting the Git workflow very soon, or who are already adopting it. This means that what they have learnt can be applied straight away, removing the danger of knowledge deteriorating prior to use. Related to this, if you can train cohorts of users who will be working together, this can be very useful as they will be able to learn and practice together. |
Contributor
|
This chapter is quite good and touches upon many challenges in change management. There is some great advice here :) |
|
|
||
| Statistical programmers in the pharmaceutical industry operate in a highly regulated environment where validated, reproducible analysis is paramount. Historically, the standard workflow revolved around statistical computing environments managed through shared network drives, strict naming conventions, and manual version control practices (saving files with incremental version numbers or descriptive suffixes before archiving) or with regular server backups. These habits, while informal, have been deeply embedded in day-to-day practice and have served as the de facto audit trail in many organizations. | ||
|
|
||
| Introducing Git into this context presents a unique set of challenges that go beyond mere tool adoption. It relies on notions such as sub-branches linked to a main branch, commits, remote repositories and merges, that can be difficult to adopt for teams used to working in other environments. The learning curve can be difficult and requires embracing a more collaborative and transparent workflow. |
Collaborator
There was a problem hiding this comment.
It introduces concepts such as branches, commits, remote repositories, pull requests, and merges that may be unfamiliar to teams accustomed to other environments.
|
|
||
| Introducing Git into this context presents a unique set of challenges that go beyond mere tool adoption. It relies on notions such as sub-branches linked to a main branch, commits, remote repositories and merges, that can be difficult to adopt for teams used to working in other environments. The learning curve can be difficult and requires embracing a more collaborative and transparent workflow. | ||
|
|
||
| Furthermore, the regulatory framework of the pharmaceutical industry is strict. Any change management system touching analysis code or submission-relevant outputs must be set in a GxP environment. Git must be used in a way that ensures compliance (traceability, audit, etc). |
Collaborator
There was a problem hiding this comment.
When Git is used as part of a process that creates or manages regulated records, its intended use and applicable GxP requirements should be defined through the organization’s quality system and a documented, risk-based assessment. Appropriate controls may include access management, traceability, review and approval, record retention, backup, and protection against unauthorized changes.
| 2) Pull Requests, and the ability to review code line by line and provide easy feedback | ||
| 3) AI Integrations which can improve code review in practice | ||
| 4) Findability and searchability of code | ||
|
|
Collaborator
There was a problem hiding this comment.
The following benefits can be demonstrated early in the adoption process:
- A traceable version history that allows programmers to compare code at different points in time.
- Pull requests that support line-by-line peer review and documented discussion.
- Parallel development through branches without overwriting another programmer’s work.
- Improved searchability and reuse of code across repositories.
- Integration with automated checks such as unit tests, package checks, and style checks.
|
|
||
| 1) The easy audit trail on a Github repository, and the ability to view code at different points in time trivially | ||
| 2) Pull Requests, and the ability to review code line by line and provide easy feedback | ||
| 3) AI Integrations which can improve code review in practice |
Collaborator
There was a problem hiding this comment.
Approved AI-assisted tools may support code review, subject to organizational policies, data-protection requirements, and appropriate human review.
|
|
||
| GxP training is of course important to meet our compliance requirements, but we can normally build training on top of it which enables more dyanmic updates as you get feedback from users on what works and what does not. | ||
|
|
||
| ### Failure cases |
Collaborator
There was a problem hiding this comment.
Troubleshooting common scenarios
| - Merge conflicts and how to resolve them smoothly | ||
| - Undoing things (git reset and revert) | ||
| - Not being able to switch brances (git stash) | ||
|
|
Collaborator
There was a problem hiding this comment.
Resolving merge conflicts safely
Reverting a change in shared history using git revert
Rewriting unshared local history using git reset, with appropriate caution
Handling uncommitted changes before switching branches using git stash or a work-in-progress commit
Resolving authentication and repository-permission issues
|
|
||
| ## Conclusion | ||
|
|
||
| Any kind of change can have large impacts on an organisation, and Git as a technology can definitely cause some friction. Just like with all changes, provided it is handed well and responsively, then within a few years the use of Git will simply be the new normal. |
Collaborator
There was a problem hiding this comment.
When the transition is handled well and supported in a responsive way, Git can become a routine and sustainable part of the statistical programming workflow.
|
|
||
| To combat this difficulty, we recommend highlighting early and often the benefits of adopting Git in practice. These are covered in more detail in the chapter on [benefits](benefits.qmd), but things you can easily show to someone who is learning Git: | ||
|
|
||
| 1) The easy audit trail on a Github repository, and the ability to view code at different points in time trivially |
Collaborator
There was a problem hiding this comment.
GitHub needs to be written as "GitHub" instead of "Github."
|
|
||
| ## Introducing tools | ||
|
|
||
| Depending on your company's size and how they want to use Git, there a number of tools to interact with Git and Github. These are covered more in the [appendix](tools.qmd), but your decision is likely to be motivated based on how close you want users to interact with Git. |
Collaborator
There was a problem hiding this comment.
there a number → there are a number
|
|
||
| - Merge conflicts and how to resolve them smoothly | ||
| - Undoing things (git reset and revert) | ||
| - Not being able to switch brances (git stash) |
|
|
||
| Where possible trainings should be live, and in person if it is possible to arrange, to allow maximum engagement. | ||
|
|
||
| One vital aspect is that training should be targetted only at individuals who are going to be adopting the Git workflow very soon, or who are already adopting it. This means that what they have learnt can be applied straight away, removing the danger of knowledge atrophying during use. Related to this, if you can train cohorts of users who will be working together, this can be very useful as they will be able to learn and practice together. |
Collaborator
There was a problem hiding this comment.
targetted → targeted
|
|
||
| ## Conclusion | ||
|
|
||
| Any kind of change can have large impacts on an organisation, and Git as a technology can definitely cause some friction. Just like with all changes, provided it is handed well and responsively, then within a few years the use of Git will simply be the new normal. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Draft PR. Currently, it's just an introduction and titles for topics I think we could work on.