diff --git a/content/departments/technical-success/support/process/change-management-checklist.md b/content/departments/technical-success/support/process/change-management-checklist.md deleted file mode 100644 index ebe6d906d78c..000000000000 --- a/content/departments/technical-success/support/process/change-management-checklist.md +++ /dev/null @@ -1,51 +0,0 @@ -# Change management checklist - -The change management checklist outlines the steps that folks on the team are required to work through in conceiving, proposing and implementing a change. These steps have been grouped into three distinct stages to align with Sourcegraph’s use of [RFCs](../../../../company-info-and-process/communication/rfcs/index.md) to frame problems and propose solutions. - -- Thinking about the idea (Pre-RFC) -- Aligning with those affected (RFC) -- Following through (Post-RFC) - -## Thinking about the idea (Pre-RFC) - -- What problem does it solve? - - Frame the problem that needs to be solved before trying to brainstorm a solution. - - Identify if/why the problem needs to be solved now. This helps us determine whether the time, effort and resources required are justified by the benefit of implementing the change or the cost of not doing so. -- Is this currently covered by our cross-functional projects? - - If yes, pause and allow ongoing projects/initiatives to run their course first so as to avoid duplication of effort and confusion within the team. - - If no, prioritize when to start against work already in-progress (to honor our work to constrain how much we have in-progress/try to do at once). -- Is this something that everyone else feels like we need? - - Validate that the problem to be solved is one that impacts the team versus one that affects a single individual. - - For leaders, this means aligning with the rest of CS leadership on the idea before facilitating a convo with the rest of the team. - - For ICs, this means validating with a few peers (or your manager if you find this helpful) then facilitating a wider convo. -- Who is impacted by this change? - - Identify who would be impacted by this change both within CS and across the organization. - - Identify who needs to be involved and in what capacity. This includes everyone on the team, others within prod/eng, and anyone cross-functionally. - - Seek consent for the capacity you identified someone for – not everyone may have time/desire to participate, so ask first. -- For leaders, will those impacted benefit more from us working privately at first and eventually publicly or publicly all the way through? - -## Aligning with those affected (RFC) - -- How much (if any) impact this change would have on current operations? - - Proposal should clearly communicate: - * How change would impact current operations - * Why it is necessary - * Measures to mitigate impact and manage transition -- Is this a change that just needs to be communicated or one that requires enablement/coaching? - - Think through “roll out” – How do we want those impacted to become aware? What about those who just need to be aware, but are not impacted? Is a Slack post enough? Is a live meeting, discussion, enablement, etc beneficial? -- Are you prepared to receive input from others? - - Acknowledge input from others and recognize feedback as a gift. Do your best to address concerns raised and appreciate other perspectives that may be different from yours. - - Ultimately, you get to make the call. Decide on the best way forward based on the information at your disposal and explain the rationale behind the course of action that you have chosen to others as clearly as possible. - -## Following through (Post-RFC) - -- Does everyone understand what action needs to be taken, by who and when? - - Create an implementation plan that clearly specifies responsible parties, assigned tasks and delivery timelines. - - Everytime something is ready for someone to take action, make the request clear and to who and why (for example, @mention folks who have action vs those who can see it but don’t; this may require asking another team who would be folks to review) - - Everytime there is a need to communicate to a new person/group, communicate contextually (you will always be many steps ahead so give others the story) – start with why, be succinct and to the point, then include all the context for whomever needs it to understand/process. -- Is there a plan to measure success and reinforce the change? - - Put a system in place to track change adoption. This could be check-ins, surveys, routine observation or reports. - - Change is hard so put a plan in place to regularly remind folks of things until the new solution/practice sticks. - - Schedule a team retro to keep track of how things are going and collect feedback for possible future iterations. - - Find ways to publicly celebrate successes (even small ones) during implementation. This could be milestone announcements in the #customer-support-internal channel (for changes within CS) or callouts for individuals in the #thanks channel (for changes with wider impact). - - To close the loop, do a self-retro of the change to determine that the problem as originally identified/framed has been solved. diff --git a/content/departments/technical-success/support/process/index.md b/content/departments/technical-success/support/process/index.md index aef1d6554751..60bc3aebb131 100644 --- a/content/departments/technical-success/support/process/index.md +++ b/content/departments/technical-success/support/process/index.md @@ -2,7 +2,6 @@ - [Updating Known Issues Page](known-issues.md) - [Case transitions](case-transitions.md) -- [Change Management Checklist](change-management-checklist.md) - [Cloud Maintenance Window Process](cloud-maintenance-window.md) - [Collaboration time](collaboration-time.md) - [Customer exceptions](customer-exceptions.md) @@ -12,7 +11,6 @@ - [Managed instances](support-managed-instances.md) - [Permanently deleting user data](permanently_deleting_user_data.md) - [Prioritization](support-prioritization.md) -- [Removing repositories from cloud](removing-repositores-from-cloud.md) - [Support capacity levels and contingencies](support-capacity-levels-and-contingencies.md) - [How to Create and Transfer Tickets for Support Engineering](support-agent-customer-slack-channels.md) - [Triaging](customer-support-triaging.md) diff --git a/content/departments/technical-success/support/process/removing-repositores-from-cloud.md b/content/departments/technical-success/support/process/removing-repositores-from-cloud.md deleted file mode 100644 index c2f3e3edc198..000000000000 --- a/content/departments/technical-success/support/process/removing-repositores-from-cloud.md +++ /dev/null @@ -1,114 +0,0 @@ -# Removing repositores from cloud - -This document is a guide on how to completely remove repositories from Sourcegraph Cloud. (Requests for repo deletion should be routed to #ask-source). - -## Prerequisites - -The user should have privileged access to be able to perform this on Sourcegraph Cloud. - -⚠️ **WARNING:** Be careful to make sure everything checks out as per the removal request. - -## Process of removing repositories - -We consider the following kinds of repositories: - -- Public forks of private repositories -- Public repositories that are made private -- Public repositories added by other users or organizations other than the owner of the repository -- Private repositories - -The removal process is the same across all the visibility types listed above. - -Depending on the environment, exec into `pgsql` following the steps below: - -For Cloud: - -Follow the steps [here](../../../engineering/dev/process/deployments/postgresql.md#connecting-to-postgres) -to connect to the database for Sourcegraph Cloud. - -For docker-compose deployments: - -**Docker** - -``` -docker exec -it $PGSQL_CONTAINER -- psql -U sg -``` - -> 🔥 You are directly interfacing with productions databases. If you are unsure of any commands, please reach out in #dev-chat or #dev-ops. - -**Option 1 ('Hard' delete)** - -A hard delete leaves no trace of the repository in the database - -1. If you know the name of the repo by it's URI get the id: - -``` -SELECT id FROM repo WHERE uri LIKE 'example.com/example/repo'; -``` - -2. Delete the repo: - -``` -DELETE FROM repo WHERE id=<$id_of_the_repo>; -``` - -**Option 2 ('Soft' delete)** - -A soft delete does not permanently delete a repository in the database and allows it to be un-deleted in the future. - -1. Get the id of the repo: - -``` -SELECT id FROM repo WHERE uri LIKE 'example.com/example/repo'; -``` - -2. Soft delete the repo: - -``` -UPDATE repo SET name = soft_deleted_repository_name(name), deleted_at = transaction_timestamp() WHERE deleted_at IS NULL AND id = ; -``` - -Note: Deleting a repository from the database does not automatically delete the data on disk (in `gitserver`). This requires an additional step. - -3. To get the correct repo in `gitserver` you will need to get it's `shard_id` by running the following command in the database: - -``` -SELECT shard_id FROM gitserver_repos where repo_id = <$id_of_the_repo> -``` - -## Removing the repository from disk - -Exec into `gitserver`: - -**Kubernetes** - -``` -kubectl exec -it $GITSERVER_POD sh -``` - -**Docker** - -``` -docker exec -it $GITSERVER_CONTAINER sh -``` - -and then - -1. `cd /data/repos/<$codehost/repo-owner>` -1. `rm -rf $repo_name` - -## Verifying the repository was removed from the database - -1. Exec into `pgsql` -1. `SELECT FROM repo WHERE name LIKE 'example.com/example/repo';` - -## Verifying the repository was removed from disk - -1. `cd /data/repos/<$codehost/repo-owner>` -2. `ls $repo_name` - -Both instances should return null results to help confirm deletion. - -### DMCA process - -Our DMCA policy for cloud is [here](https://about.sourcegraph.com/terms-cloud/#10-Copyright-infringement-and-DMCA-policy)