mirror of
https://github.com/kanidm/kanidm.git
synced 2025-02-23 20:47:01 +01:00
b8dcb47f93
* codespell run and spelling fixes * some clippying * minor fmt fix * making yamllint happy * adding codespell github action
68 lines
3.1 KiB
Markdown
68 lines
3.1 KiB
Markdown
# Developer Principles
|
|
|
|
As a piece of software that stores the identities of people, the project becomes bound to social and
|
|
political matters. The decisions we make have consequences on many people - many who never have the
|
|
chance to choose what software is used to store their identities (think employees in a business).
|
|
|
|
This means we have a responsibility to not only be aware of our impact on our direct users
|
|
(developers, system administrators, dev ops, security and more) but also the impact on indirect
|
|
consumers - many of who are unlikely to be in a position to contact us to ask for changes and help.
|
|
|
|
## Ethics / Rights
|
|
|
|
If you have not already, please see our documentation on [rights and ethics]
|
|
|
|
[rights and ethics]: https://github.com/kanidm/kanidm/blob/master/ethics/README.md
|
|
|
|
## Humans First
|
|
|
|
We must at all times make decisions that put humans first. We must respect all cultures, languages,
|
|
and identities and how they are represented.
|
|
|
|
This may mean we make technical choices that are difficult or more complex, or different to "how
|
|
things have always been done". But we do this to ensure that all people can have their identities
|
|
stored how they choose.
|
|
|
|
For example, any user may change their name, display name and legal name at any time. Many
|
|
applications will break as they primary key from name when this occurs. But this is the fault of the
|
|
application. Name changes must be allowed. Our job as technical experts is to allow that to happen.
|
|
|
|
We will never put a burden on the user to correct for poor designs on our part. For example, locking
|
|
an account if it logs in from a different country unless the user logs in before hand to indicate
|
|
where they are going. This makes the user responsible for a burden (changing the allowed login
|
|
country) when the real problem is preventing bruteforce attacks - which can be technically solved in
|
|
better ways that don't put administrative load to humans.
|
|
|
|
## Correct and Simple
|
|
|
|
As a piece of security sensitive software we must always put correctness first. All code must have
|
|
tests. All developers must be able to run all tests on their machine and environment of choice.
|
|
|
|
This means that the following must always work:
|
|
|
|
```bash
|
|
git clone ...
|
|
cargo test
|
|
```
|
|
|
|
If a test or change would require extra requirements, dependencies, or preconfiguration, then we can
|
|
no longer provide the above. Testing must be easy and accessible, else we won't do it, and that
|
|
leads to poor software quality.
|
|
|
|
The project must be simple. Any one should be able to understand how it works and why those
|
|
decisions were made.
|
|
|
|
## Languages
|
|
|
|
The core server will (for now) always be written in Rust. This is due to the strong type guarantees
|
|
it gives, and how that can help raise the quality of our project.
|
|
|
|
## Over-Configuration
|
|
|
|
Configuration will be allowed, but only if it does not impact the statements above. Having
|
|
configuration is good, but allowing too much (IE a scripting engine for security rules) can give
|
|
deployments the ability to violate human first principles, which reflects badly on us.
|
|
|
|
All configuration items, must be constrained to fit within our principles so that every kanidm
|
|
deployment, will always provide a positive experience to all people.
|