Remove mentions of Product Team

content/en/contribute/medic/product-development-process/quality-assistance.md → content/en/contribute/code/quality-assistance.md

@@ -1,9 +1,11 @@
 ---
 title: "Quality Assistance"
 linkTitle: "Quality Assistance"
-weight: 5
+weight: 15
 description: >
   How the Quality Assistance process works at Medic
+aliases:
+   - /contribute/medic/product-development-process/quality-assistance
 ---
 
 ## Goals
@@ -31,7 +33,7 @@ The big difference to that AT step though will be the depth in which it is perfo
 There may still be cases of a ticket getting coded up totally unrelated to Focused Working Group work, perhaps even unannounced to anyone. For work like this the traditional AT step is still appropriate for now. Still though, it is preferred for the software developer to get a QA engineer involved as early as possible; it helps us get the best contributions from everyone.
 
 ## An Example of QA Assistance in Practice
-Imagine a scenario where a Focused Working Group is going to change the display of the targets screen. The group would discuss the needs of the users and work out solutions, where the selected solution was to make this change. This discussion would involve a PM/PO, designer, developer, and QA engineer. The developer would be thinking about how to code the proposed solution and the QA engineer would be considering that as well as what might go wrong.
+Imagine a scenario where a community member or a squad is going to change the display of the targets screen. The group would discuss the needs of the users and work out solutions, where the selected solution was to make this change. This discussion could involve involve project managers, designers, developers, and QA engineers. The developer would be thinking about how to code the proposed solution and the QA engineer would be considering that as well as what might go wrong.
 
 In the case where a UI change is being made, a design will be created. At this point the group can see what is to be built. When meeting and discussing the user interactions with the designer the QA engineer can get some early ideas around test scenarios.
 
@@ -50,6 +52,6 @@ At this point the ideal action to take would be that the developer merges the fi
 The last part here is to merge it. That extra poking around should be quick, so the developer should be ready to click the green button soon!
 
 ## But, but, but!!! (some questions you might have)
-- Who checks if the right thing got built? – The Focused Working Group members should be aware of what’s being built, why, and if it’s coming together as expected. That’s not to be solely delegated to a QA engineer to do. Developers should be working with their teammates and showing their work (demos, screenshots, etc). This should feel like a team collaborating to build useful working software, not an assembly line of disassociated parts.
+- Who checks if the right thing got built? – The community/squad members should be aware of what’s being built, why, and if it’s coming together as expected. That’s not to be solely delegated to a QA engineer to do. Developers should be working with the community and showing their work (demos, screenshots, etc). This should feel like a team collaborating to build useful working software, not an assembly line of disassociated parts.
 - What if a developer is bad at testing? – That’s something to improve, not outsource to someone else. Even still, the QA engineer isn’t disappearing and they will still offer deeper advice on what tests the developer should perform.
 - What will QA engineers do if not doing manual acceptance testing? – Automating more. That can be in more end-to-end tests for better regression testing, automating mobile device testing, adding better structures to enable the whole team to automate better, improving CI pipeline, etc.

content/en/contribute/code/releasing/_index.md

@@ -16,12 +16,12 @@ A release is a set of code changes bundled together, ideally with at least one d
 
 The high-level steps for a release are as follows:
 
-* The [Focused Working Group]({{% ref "/contribute/medic/product-development-process/focused-groups" %}}) sees an opportunity they want to go after. The opportunity addresses a need of at least one CHT app deployment and will be used by that deployment after the release.
-* The Focused Working Group agrees on a solution for it.
-* Tickets are added to the [Product Team Activities board](https://github.com/orgs/medic/projects/134/views/3) for what's being built.
+* The CHT Community sees an opportunity they want to go after. The opportunity addresses a need of at least one CHT app deployment and will be used by that deployment after the release.
+* The CHT Community forms a squad and works with it on a solution.
+* Tickets are added to GitHub for what's being built.
 * A [release manager](#release-manager) is assigned from the team.
 * The release manager [creates an issue](https://github.com/medic/cht-core/issues/new/choose) for either a [Major/Minor or Patch](#majorminorpatch-release) release and follows the process outlined in the issue template.
-* Code is built by a developer together with [quality assistance]({{% ref "/contribute/medic/product-development-process/quality-assistance" %}}).
+* Code is built by a developer together with [quality assistance]({{% ref "/contribute/code/quality-assistance" %}}).
 * [Code is reviewed]({{% ref "/contribute/code/workflow#code-reviews" %}}).
 * Code is merged.
 * Code is released.

content/en/contribute/code/workflow.md

@@ -30,7 +30,7 @@ When a bug is found that impacts functionality that worked in a previous version
 
 ### Issue Status
 
-When the issue is scheduled for development it will be added to the [Product Team Activities project](https://github.com/orgs/medic/projects/134). The issue has a status property that represents the state the issue is in.
+When the issue is scheduled for development it will be added to a project. The issue has a status property that represents the state the issue is in.
 
 #### To do
 
@@ -188,7 +188,7 @@ Code reviews should be completed within 24 hours of assignment (excluding weeken
 
 ### Testing
 
-Reach out to the Quality Assurance Engineers with the work to be done as early as possible in the development process to ensure they are informed and can guide development (see more in the [Quality Assistance]({{< ref "contribute/medic/product-development-process/quality-assistance" >}}) dedicated page).
+Reach out to the Quality Assurance Engineers with the work to be done as early as possible in the development process to ensure they are informed and can guide development (see more in the [Quality Assistance]({{< ref "contribute/code/quality-assistance" >}}) dedicated page).
 
 Before asking for testing support from the QA Engineers, you should test your work after performing it. Correcting a small code error, such as a typo, or adding a missing step in the testing instructions could save QA Engineers hours of work. Also, by testing your code, you may get a better sense of why you make certain common mistakes, and learn to avoid repeating them in the future.
 

content/en/contribute/medic/_index.md

@@ -3,11 +3,7 @@ title: "At Medic"
 linkTitle: "At Medic"
 weight: 7
 description: >
-  Compilation of guidelines and product development processes used at Medic 
+  Compilation of guidelines internal to Medic 
 ---
 
-[Medic](https://medic.org) works with CHT partners and health workers to design, build, and maintain the Community Health Toolkit and its open source tools. Medic's Product team manages the entire software development life-cycle to understand problems, capture requirements, design and build modular software systems, and document everything along the way.
-
-This section contains internal processes, best practices and guidelines used *so far* in the Product team at Medic.
-
-**Also, improvements and ideas for this doc site are [always welcome]({{% ref "contribute/docs" %}})!**
+This section contains processes and guidelines internal to Medic.

content/en/contribute/medic/onboarding/all-the-things.md

@@ -19,13 +19,9 @@ This page is meant to serve as a point of conversation, with a wide range of top
 
 ### Teams at Medic
 Meet the [Medic team](https://medic.org/team/)!
-* [Product]({{% ref "contribute/medic/onboarding/product-team" %}})
-* Programs
-* Internal Operations
-* External Affairs
 
 ### Lifecycle of a [CHT Application]({{% ref "/running-programs/#cht-lifecycle" %}}) being built
-1. Programs team starts relationship with an organization.
+1. A program or initiative is started by one or multiple organizations.
 1. Service designers and app developers figure out how they want their system to work.
 1. App developers take latest version of the CHT and build the app for the organization.
 1. Android flavor deployed to get branded app onto CHW devices / deployment.
@@ -56,23 +52,23 @@ Medic relies on both restricted and unrestricted funds to support our mission.
 
 #### Travel 
 * Team Meetups are a great way to build relations with your team! These are usually planned weeks ahead; if you feel comfortable joining, please do!
-* Focused Working Groups team members may sometimes organize in-person meetups to meet with the people they serve. It's highly recommended to join those trips to get more connected to the team and the mission! 
+* The different teams may sometimes organize in-person meetups to meet with the people from the community. It's highly recommended to join those trips to get more connected to the community and the mission! 
 
 #### Meetings
 * There a few calls where you will be required to join. We know that depending on your timezone, you might need to adjust your calendar to be able to attend and we provide great flexibility to do so. 
 * Organization-wide calls are recorded.
 * No meetings on Fridays, as we consider Fridays as Deep Work days! 
 * Retrospective sessions
-* Weekly Focused Working Groups meetings
+* Weekly team meetings
 * Weekly 1-to-1s with your manager
 
 ### Process
 
 #### Development
-* [Current development process]({{% ref "contribute/code/workflow" %}}). Keep in mind to involve [Quality Assistance]({{% ref "contribute/medic/product-development-process/quality-assistance" %}}) from the start. 
+* [Current development process]({{% ref "contribute/code/workflow" %}}). Keep in mind to involve [Quality Assistance]({{% ref "contribute/code/quality-assistance" %}}) from the start. 
 * [Releasing]({{% ref "contribute/code/releasing" %}})
 * Backwards compatibility matters a lot, so CHWs can keep using the app and delivery care to their community without interruptions. 
-* It can feel slow at times, but we’re making a lot of progress here. See below about how Focused Working Groups work.
+* It can feel slow at times, but we’re making a lot of progress here.
 * Quality matters a lot!
 * [Data Flow]({{% ref "core/overview/data-flows-for-analytics" %}})
 * [Monitoring & Alerting]({{% ref "hosting/monitoring" %}})
@@ -90,12 +86,6 @@ Medic relies on both restricted and unrestricted funds to support our mission.
 #### GitHub 
 * Tons of things happen here.
 * Recommendation: [Set up your reminders/notifications](https://medic.slack.com/archives/C024KTGRW/p1617308776092600) 
-* A few important boards: 
-  * [SRE Support](https://github.com/orgs/medic/projects/19)
-  * [Ecosystem Workstream](https://github.com/orgs/medic/projects/134/views/11)
-  * [Allies Workstream](https://github.com/orgs/medic/projects/134/views/3)
-  * [Care Teams Workstream](https://github.com/orgs/medic/projects/134/views/2)
-  * [Test Automation](https://github.com/orgs/medic/projects/134/views/12)
 
 #### Quality Assistance
 * High emphasis on automation
@@ -110,26 +100,13 @@ Medic relies on both restricted and unrestricted funds to support our mission.
 * Not on-call
 * We’re offline first, so not every outage calls for immediate action/resolution.
 
-### Product
-#### [CHT Forum](https://forum.communityhealthtoolkit.org/)
+
+### [CHT Forum](https://forum.communityhealthtoolkit.org/)
 * We keep the forum active. It's a great place to talk with people working with the CHT.
 * Encourage teammates to post and answer questions there instead of Slack when the community might benefit
 * Expecting you to be proactive and support the team with checking forum posts and helping when questions arise
 
-#### Partners
-* Medic-hosted
-* Self-hosted
-* Technical partners
-
-#### Product Development Process
-* At Medic, we follow [Continuous Discovery]({{% ref "continuous-discovery-overview" %}}) as a [Product Development Process]({{% ref "product-development-process" %}})
-  * Trying to follow closely with the [Continuous Discovery Habits](https://www.producttalk.org/2021/05/continuous-discovery-habits/) book by Teresa Torres
-  * [Focused Working Groups]({{% ref "focused-groups" %}}) within the product team to focus on specific groups of users
-    * Allies
-    * Care Teams
-    * Ecosystem
-
-#### Technology Radars
+### Technology Radars
 * A [Technology Radar]({{% ref "contribute/tech-radar" %}}) is a compilation of technologies and their adoption status in the context of the CHT. When in doubt of using a certain technology or feature of the CHT, check the radars for their adoption status.
   * [CHT Technology Radar for Contributors](https://docs.communityhealthtoolkit.org/cht-tech-radar-contributors/index.html)
   * [CHT Technology Radar for Implementers](https://docs.communityhealthtoolkit.org/cht-tech-radar-implementers/index.html).