2 files changed, 15 insertions, 3 deletions

diff --git a/docs/dev/README.md b/docs/dev/README.md
index 9c0eb1358..f74f7d8eb 100644
--- a/docs/dev/README.md
+++ b/docs/dev/README.md
@@ -235,12 +235,14 @@ We don't do "patch" releases, unless something truly egregious comes up.
 
 There are three sets of people with extra permissions:
 
-* rust-analyzer GitHub organization **admins** (which include current t-compiler leads).
+* rust-analyzer GitHub organization (**admins**)[https://github.com/orgs/rust-analyzer/people?query=role:owner] (which include current t-compiler leads).
   Admins have full access to the org.
-* **review** team in the organization.
+* (**review**)[https://github.com/orgs/rust-analyzer/teams/review] team in the organization.
   Reviewers have `r+` access to all of organization's repositories and publish rights on crates.io.
   They also have direct commit access, but all changes should via bors queue.
   It's ok to self-approve if you think you know what you are doing!
   bors should automatically sync the permissions.
-* **triage** team in the organization.
+* (**triage**)[https://github.com/orgs/rust-analyzer/teams/triage] team in the organization.
   This team can label and close issues.
+
+Note that at the time being you need to be a member of the org yourself to view the links.
diff --git a/docs/dev/style.md b/docs/dev/style.md
index 468dedff2..7c47c26b2 100644
--- a/docs/dev/style.md
+++ b/docs/dev/style.md
@@ -152,6 +152,16 @@ Do not reuse marks between several tests.
 
 **Rationale:** marks provide an easy way to find the canonical test for each bit of code.
 This makes it much easier to understand.
+More than one mark per test / code branch doesn't add significantly to understanding.
+
+## `#[should_panic]`
+
+Do not use `#[should_panic]` tests.
+Instead, explicitly check for `None`, `Err`, etc.
+
+**Rationale:**a `#[should_panic]` is a tool for library authors, to makes sure that API does not fail silently, when misused.
+`rust-analyzer` is not a library, we don't need to test for API misuse, and we have to handle any user input without panics.
+Panic messages in the logs from the `#[should_panic]` tests are confusing.
 
 ## Function Preconditions