Initial commit

A mailing list implementation by POuL for POuL that aims to be minimal
but use SMTP to deliver receiving emails instead of LMTP. This is
because mailing list software that use LMTP as their delivery mechanism
make achieving modularized container environments harder. This is due to
the fact that mailing lists that use LMTP require it and the main MTA to
live on the same machine.

This implementation aims to be good enough to be used as the mailing
list for POuL in its kubernetes infrastructure (and frankly, it was
about time that someone implemented a mailing list that could be
"standalone" in containers).

Signed-off-by: Mroik <mroik@delayed.space>

1 files changed, 41 insertions, 0 deletions

diff --git a/README.md b/README.md
new file mode 100644
index 0000000..e4b8bdd
--- /dev/null
+++ b/README.md
@@ -0,0 +1,41 @@
+# POuL-list
+A mailing list by [POuL](https://poul.org/) (currently maintained by
+[Mroik](https://gitlab.poul.org/mroik)).
+
+## Codestyle
+So long as it passes `cargo fmt --check` it is fine.
+
+## Commit messages
+When writing a commit message you may choose whatever style you prefer for the
+subject line. The important thing is that the subject line is followed by one
+or more paragraphs explaining the reasoning behind the change (this can be
+omitted for trivial stuff at the discretion of the maintainer).
+
+## Contribution process
+Development happens mainly on https://gitlab.poul.org/  
+If you're not a POuL member you can send patches directly to the maintainer
+(you can check the commit history for the email).
+
+Here's how a contribution cycle should go:
+1. A review process starts only after an MR is open and marked as ready
+2. There will be the usual discussion on the issues with the MR and suggestions
+   on how to fix it.
+3. A new iteration will be sent by the author. Improvements should not be built
+   on top of the existing commits (unless making new ones make sense of
+   course), instead the author is expected to amend the commits with the
+   changes required. This keeps the history clean for those who'll come after.
+   * Anyone is welcome to review (it is encouraged)
+   * If the reviewer is not the maintainer then the reviewer will be given
+     recognition through the `Reviewed-by` trailer. This is not only to give
+     recognition, but it also has an additional `blame` functionality.
+4. Points (2) and (3) are repeated until the MR reaches a satisfactory state
+5. Before the commits are merged the maintainer will amend the commits by
+   adding their own signoff (as proof of acknowledgment)
+6. The MR is merged
+
+## Signoff
+All commits should be signed-off. A sign off in this project certifies your
+work under the [DCO](https://developercertificate.org/).
+
+By signing off you also declare that you understand and will adhere to the
+contribution process.