Update 11 principles page

[melindafekete]

About the changes

An extension of #7801.

Docs preview

Key changes:

• Improved readability—removed a lot of passive voice, made sections a bit less repetitive and reorganized a few sentences/headings for better structure.

• Removed nested lists. I generally avoid using numbered lists, unless it's instructions or something that really calls for an order. I think it's fine to keep the high-level 11-step list (because 11 principles sounds catchy) but I would avoid nested lists like 1.1.a in this case.

• Added some more links to tie back to some of the Unleash concepts in a subtle way. For example, linking the 4-eyes principle to the change requests docs.

• Made the principles titles a bit more concise and readable.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
unleash-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 20, 2024 3:10pm
unleash-monorepo-frontend	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 20, 2024 3:10pm

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

OpenSSF Scorecard

Package	Version	Score	Details

Scanned Manifest Files

[melindafekete]

@michaelferranti wdyt about making the principles a bit more snappy?

Current:
1. Enable runtime control: Control flags dynamically instead of through config files.
2. Never expose PII: Follow the principle of least privilege.
3. Reduce latency: Evaluate flags as close to the user as possible.
4. Scale horizontally: Decouple read and write operations.
5. Limit payload size: Keep feature flag payload lean.
6. Design for failure: Prioritize availability over consistency.
7. Use short-lived flags: Do not confuse flags with application configuration.
8. Use unique flag names: Enforce naming conventions.
9. Choose open by default: Democratize feature flag access.
10. Do no harm: Prioritize consistent user experience.
11. Enable traceability: Make flag evaluation transparent and testable.

Some ideas:
1. Evaluate flags at runtime
2. Protect PII by evaluating flags server-side
3. Evaluate flags as close to the user as possible (OR Evaluate flags locally)
4. Scale horizontally by decoupling reads and writes
5. Limit feature flag payload
6. Prioritize availability over consistency
7. Use short-lived flags
8. Ensure unique flag names
9. Choose open by default (OR Choose open collaboration by default)
10. Ensure consistent user experience
11. Optimize for developer experience

[ferrantim]

@melindafekete I am good with your proposed changes to the FF principles. They are consistent with what we are trying to communicate.

[ferrantim]

LGTM. Just a few changes.