diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index b25a131d44..cb06a17e77 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,92 +1,77 @@
 # Contributing
 
-- [How to Contribute](#how-to-contribute)
-  * [Getting Code](#getting-code)
-  * [Code reviews](#code-reviews)
-  * [Code Style](#code-style)
-  * [API guidelines](#api-guidelines)
-  * [Commit Messages](#commit-messages)
-  * [Writing Documentation](#writing-documentation)
-  * [Adding New Dependencies](#adding-new-dependencies)
-  * [Running & Writing Tests](#running--writing-tests)
-  * [Public API Coverage](#public-api-coverage)
-- [Contributor License Agreement](#contributor-license-agreement)
-  * [Code of Conduct](#code-of-conduct)
+## Choose an issue
 
-## How to Contribute
+Playwright **requires an issue** for every contribution, except for minor documentation updates. We strongly recommend to pick an issue labeled `open-to-a-pull-request` for your first contribution to the project.
 
-We strongly recommend that you open an issue before beginning any code modifications. This is particularly important if the changes involve complex logic or if the existing code isn't immediately clear. By doing so, we can discuss and agree upon the best approach to address a bug or implement a feature, ensuring that our efforts are aligned.
+If you are passioned about a bug/feature, but cannot find an issue describing it, **file an issue first**. This will facilitate the discussion and you might get some early feedback from project maintainers before spending your time on creating a pull request.
 
-### Getting Code
-
-Make sure you're running Node.js 20 to verify and upgrade NPM do:
+## Make a change
 
+Make sure you're running Node.js 20 or later.
 ```bash
 node --version
-npm --version
-npm i -g npm@latest
 ```
 
-1. Clone this repository
-
-    ```bash
-    git clone https://github.com/microsoft/playwright
-    cd playwright
-    ```
-
-2. Install dependencies
-
-    ```bash
-    npm ci
-    ```
-
-3. Build Playwright
-
-    ```bash
-    npm run build
-    ```
-
-4. Run tests
-
-    This will run a test on line `23` in `page-fill.spec.ts`:
-
-    ```bash
-    npm run ctest -- page-fill:23
-    ```
-
-    See [here](#running--writing-tests) for more information about running and writing tests.
-
-### Code reviews
-
-All submissions, including submissions by project members, require review. We
-use GitHub pull requests for this purpose. Consult
-[GitHub Help](https://help.github.com/articles/about-pull-requests/) for more
-information on using pull requests.
-
-### Code Style
-
-- Coding style is fully defined in [.eslintrc](https://github.com/microsoft/playwright/blob/main/.eslintrc.js)
-- Comments should be generally avoided. If the code would not be understood without comments, consider re-writing the code to make it self-explanatory.
-
-To run code linter, use:
-
+Clone the repository. If you plan to send a pull request, it might be better to [fork the repository](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo) first.
 ```bash
-npm run eslint
+git clone https://github.com/microsoft/playwright
+cd playwright
 ```
 
-### API guidelines
+Install dependencies and run the build in watch mode.
+```bash
+npm ci
+npm run watch
+npx playwright install
+```
 
-When authoring new API methods, consider the following:
+Playwright is a multi-package repository that uses npm workspaces. For browser APIs, look at [`packages/playwright-core`](https://github.com/microsoft/playwright/blob/main/packages/playwright-core). For test runner, see [`packages/playwright`](https://github.com/microsoft/playwright/blob/main/packages/playwright).
 
-- Expose as little information as needed. When in doubt, don’t expose new information.
-- Methods are used in favor of getters/setters.
-  - The only exception is namespaces, e.g. `page.keyboard` and `page.coverage`
-- All string literals must be lowercase. This includes event names and option values.
-- Avoid adding "sugar" API (API that is trivially implementable in user-space) unless they're **very** common.
+Note that some files are generated by the build, so the watch process might override your changes if done in the wrong file. For example, TypeScript types for the API are generated from the [`docs/src`](https://github.com/microsoft/playwright/blob/main/docs/src).
 
-### Commit Messages
+Coding style is fully defined in [.eslintrc](https://github.com/microsoft/playwright/blob/main/.eslintrc.js). Before creating a pull request, or at any moment during development, run linter to check all kinds of things:
+  ```bash
+  npm run lint
+  ```
 
-Commit messages should follow the Semantic Commit Messages format:
+Comments should be generally avoided. If the code would not be understood without comments, consider re-writing the code to make it self-explanatory.
+
+### Write documentation
+
+Every part of the public API should be documented in [`docs/src`](https://github.com/microsoft/playwright/blob/main/docs/src), in the same change that adds/changes the API. We use markdown files with custom structure to specify the API. Take a look around for an example.
+
+Various other files are generated from the API specification. If you are running `npm run watch`, these will be re-generated automatically.
+
+Larger changes will require updates to the documentation guides as well. This will be made clear during the code review.
+
+## Add a test
+
+Playwright requires a test for almost any new or modified functionality. An exception would be a pure refactoring, but chances are you are doing more than that.
+
+There are multiple [test suites](https://github.com/microsoft/playwright/blob/main/tests) in Playwright that will be executed on the CI. The two most important that you need to run locally are:
+
+- Library tests cover APIs not related to the test runner.
+  ```bash
+  # fast path runs all tests in Chromium
+  npm run ctest
+
+  # slow path runs all tests in three browsers
+  npm run test
+  ```
+
+- Test runner tests.
+  ```bash
+  npm run ttest
+  ```
+
+Since Playwright tests are using Playwright under the hood, everything from our documentation applies, for example [this guide on running and debugging tests](https://playwright.dev/docs/running-tests#running-tests).
+
+Note that tests should be *hermetic*, and not depend on external services. Tests should work on all three platforms: macOS, Linux and Windows.
+
+## Write a commit message
+
+Commit messages should follow the [Semantic Commit Messages](https://www.conventionalcommits.org/en/v1.0.0/) format:
 
 ```
 label(namespace): title
@@ -97,131 +82,57 @@ footer
 ```
 
 1. *label* is one of the following:
-    - `fix` - playwright bug fixes.
-    - `feat` - playwright features.
-    - `docs` - changes to docs, e.g. `docs(api): ..` to change documentation.
-    - `test` - changes to playwright tests infrastructure.
-    - `devops` - build-related work, e.g. CI related patches and general changes to the browser build infrastructure
+    - `fix` - bug fixes
+    - `feat` - new features
+    - `docs` - documentation-only changes
+    - `test` - test-only changes
+    - `devops` - changes to the CI or build
     - `chore` - everything that doesn't fall under previous categories
-2. *namespace* is put in parenthesis after label and is optional. Must be lowercase.
-3. *title* is a brief summary of changes.
-4. *description* is **optional**, new-line separated from title and is in present tense.
-5. *footer* is **optional**, new-line separated from *description* and contains "fixes" / "references" attribution to github issues.
+1. *namespace* is put in parenthesis after label and is optional. Must be lowercase.
+1. *title* is a brief summary of changes.
+1. *description* is **optional**, new-line separated from title and is in present tense.
+1. *footer* is **optional**, new-line separated from *description* and contains "fixes" / "references" attribution to github issues.
 
 Example:
 
 ```
-fix(firefox): make sure session cookies work
+feat(trace viewer): network panel filtering
 
-This patch fixes session cookies in the firefox browser.
+This patch adds a filtering toolbar to the network panel.
+<link to a screenshot>
 
-Fixes #123, fixes #234
+Fixes #123, references #234.
 ```
 
-### Writing Documentation
+## Send a pull request
 
-All API classes, methods, and events should have a description in [`docs/src`](https://github.com/microsoft/playwright/blob/main/docs/src). There's a [documentation linter](https://github.com/microsoft/playwright/tree/main/utils/doclint) which makes sure documentation is aligned with the codebase.
+All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult [GitHub Help](https://help.github.com/articles/about-pull-requests/) for more information on using pull requests.
 
-To run the documentation linter, use:
+After a successful code review, one of the maintainers will merge your pull request. Congratulations!
 
+## More details
+
+**No new dependencies**
+
+There is a very high bar for new dependencies, including updating to a new version of an existing dependency. We recommend to explicitly discuss this in an issue and get a green light from a maintainer, before creating a pull request that updates dependencies.
+
+**Custom browser build**
+
+To run tests with custom browser executable, specify `CRPATH`, `WKPATH` or `FFPATH` env variable that points to browser executable:
 ```bash
-npm run doc
+CRPATH=<path-to-executable> npm run ctest
 ```
 
-To build the documentation site locally and test how your changes will look in practice:
+You will also find `DEBUG=pw:browser` useful for debugging custom builds.
 
-1. Clone the [microsoft/playwright.dev](https://github.com/microsoft/playwright.dev) repo
-1. Follow [the playwright.dev README instructions to "roll docs"](https://github.com/microsoft/playwright.dev/#roll-docs) against your local `playwright` repo with your changes in progress
-1. Follow [the playwright.dev README instructions to "run dev server"](https://github.com/microsoft/playwright.dev/#run-dev-server) to view your changes
+**Building documentation site**
 
-### Adding New Dependencies
+The [playwright.dev](https://playwright.dev/) documentation site lives in a separate repository, and documentation from [`docs/src`](https://github.com/microsoft/playwright/blob/main/docs/src) is frequently rolled there.
 
-For all dependencies (both installation and development):
-- **Do not add** a dependency if the desired functionality is easily implementable.
-- If adding a dependency, it should be well-maintained and trustworthy.
-
-A barrier for introducing new installation dependencies is especially high:
-- **Do not add** installation dependency unless it's critical to project success.
-
-### Running & Writing Tests
-
-- Every feature should be accompanied by a test.
-- Every public api event/method should be accompanied by a test.
-- Tests should be *hermetic*. Tests should not depend on external services.
-- Tests should work on all three platforms: Mac, Linux and Win. This is especially important for screenshot tests.
-
-Playwright tests are located in [`tests`](https://github.com/microsoft/playwright/blob/main/tests) and use `@playwright/test` test runner.
-These are integration tests, making sure public API methods and events work as expected.
-
-- To run all tests:
-
-    ```bash
-    npx playwright install
-    npm run test
-    ```
-
-    Be sure to run `npm run build` or let `npm run watch` run before you re-run the
-    tests after making your changes to check them.
-
-- To run tests in Chromium
-
-    ```bash
-    npm run ctest # also `ftest` for firefox and `wtest` for WebKit
-    npm run ctest -- page-fill:23 # runs line 23 of page-fill.spec.ts
-    ```
-
-- To run tests in WebKit / Firefox, use `wtest` or `ftest`.
-
-- To run the Playwright test runner tests
-
-    ```bash
-    npm run ttest
-    npm run ttest -- --grep "specific test"
-    ```
-
-- To run a specific test, substitute `it` with `it.only`, or use the `--grep 'My test'` CLI parameter:
-
-    ```js
-    ...
-    // Using "it.only" to run a specific test
-    it.only('should work', async ({server, page}) => {
-      const response = await page.goto(server.EMPTY_PAGE);
-      expect(response.ok).toBe(true);
-    });
-    // or
-    playwright test --config=xxx --grep 'should work'
-    ```
-
-- To disable a specific test, substitute `it` with `it.skip`:
-
-    ```js
-    ...
-    // Using "it.skip" to skip a specific test
-    it.skip('should work', async ({server, page}) => {
-      const response = await page.goto(server.EMPTY_PAGE);
-      expect(response.ok).toBe(true);
-    });
-    ```
-
-- To run tests in non-headless (headed) mode:
-
-    ```bash
-    npm run ctest -- --headed
-    ```
-
-- To run tests with custom browser executable, specify `CRPATH`, `WKPATH` or `FFPATH` env variable that points to browser executable:
-
-    ```bash
-    CRPATH=<path-to-executable> npm run ctest
-    ```
-
-- When should a test be marked with `skip` or `fixme`?
-
-  - **`skip(condition)`**: This test *should ***never*** work* for `condition`
-    where `condition` is usually something like: `test.skip(browserName === 'chromium', 'This does not work because of ...')`.
-
-  - **`fixme(condition)`**: This test *should ***eventually*** work* for `condition`
-    where `condition` is usually something like: `test.fixme(browserName === 'chromium', 'We are waiting for version x')`.
+Most of the time this should not concern you. However, if you are doing something unusual in the docs, you can build locally and test how your changes will look in practice:
+1. Clone the [microsoft/playwright.dev](https://github.com/microsoft/playwright.dev) repo.
+1. Follow [the playwright.dev README instructions to "roll docs"](https://github.com/microsoft/playwright.dev/#roll-docs) against your local `playwright` repo with your changes in progress.
+1. Follow [the playwright.dev README instructions to "run dev server"](https://github.com/microsoft/playwright.dev/#run-dev-server) to view your changes.
 
 ## Contributor License Agreement