Rewrite docs on organizations and projects, with per-project permissions

[Twixes]

Changes

Completely rewritten docs on organizations and projects to make them much more comprehensive.

Also, importantly, included section "Per-project permissions" – this outlines the solution to PostHog/posthog#4263 that I'm currently implementing. Feel free to suggest any change to part, as all details can still be changed.

Checklist

• Titles are in sentence case
• Words are spelled using American english
• I have checked out our styleguide

[paolodamico]

Thanks @Twixes, this makes it a lot clearer! Minor comments inline, in addition project-based permissions should be an ee feature (see https://github.com/PostHog/company-internal/issues/417)

[Twixes]

Good points, addressed @paolodamico

[leggetter]

A few small but worthwhile changes requested.

Generally really well explained.

Two main comments:

• The intro paragraph needs to do more to explain the value of these concepts and organisational constructs
• We should probably capitalise Organization and Project when being used as a noun

[Twixes]

Good points @leggetter, I'm not sure about capitalizing these words here though.
The idea has some merit to me, as they're sort of distinct concepts, but I think this should be clearly explained in the style guide if we want to do this, because there's more concepts like this, and there are some edge cases. For instance, should it be "Organization invite" or "Organization Invite". Also, since there's access level "Member" I use lower-case "member" as "any organization member" and "Member" as "Member-level organization member", which would be lost if we capitalized that noun too.
So I'd rather do that in another PR.

[paolodamico]

Made suggestions inline, but looking pretty solid!

[Twixes]

Alright, used some suggestions but also changed a few. @paolodamico I would suggest with this number of suggestions to just create a PR on top of the one being edited in the future, as an article loses cohesiveness with multiple individual-line edits.

Added the PR to the Artwork board, not high priority, but it could be nice to have an illustration (referring to #1948 (comment)).

[paolodamico]

Suggested change

	If you'd like to restrict access to data within the organization to only those who need it, you can make a project _private_. Projects with this setting enabled become **secret by default and invite-only** (except for Administrators and the Owner, who get access implicitly).
	If you'd like to restrict access to data within the organization to only those who need it, you can make a project _private_. Projects with this setting enabled become **private by default and invite-only** (except for Administrators and the Owner, who get access implicitly).

I'm sorry, I know I made this suggestion but just realized secret implies that it's completely hidden from other members, but it's not secret (other team members can still see it exists and its name), it's private

[Twixes]

Ah, I thought it was a conscious suggestion to make them secret in the product too, but very well, let's just keep them private as currently implemented.

[paolodamico]

I think it's fine to keep it like this, we can get more feedback from users in the upcoming weeks as to whether there's a use case for secret projects, but my guess is that it won't.

[paolodamico]

Thanks @Twixes! Definitely, my apologies didn't realize I would be making many suggestions.

[leggetter]

@Twixes - is this just about good to be merged?

[Twixes]

It would be, but first we need to release PostHog/posthog#4263 to the public. :) These docs are false until the feature is released.