+* *keep in touch* about what you are doing, and why you are doing it.
+* edit your home page regularly, particularly to track tasks so that they can be paid by NLNet.
+* if you cannot do something that you have taken responsibility for,
+ then unless it is a dire personal emergency please say so, on-list. we
+ won't mind. we'll help sort it out.
+
+regarding the above it is important that you read, understand, and agree
+to the [[charter]] because the charter is about ensuring that we operate
+as an effective organisation. It's *not* about "setting rules and meting
+out punishment".
+
+## Coding
+
+for actual code development
+
+### Plan unit tests
+
+* plan in advance to write not just code but a full test suite for
+ that code. **this is not optional**. large python projects that do not
+ have unit tests **FAIL** (see separate section below).
+* Prioritise writing formal proofs and a single clear unit test that is more like a "worked example".
+ We receive NLNet funds for writing formal proofs, plus they
+cover corner cases and take far less time to write
+
+### Commit tested or zero-dependent code
+
+* only commit code that has been tested (or is presently unused). other
+ people will be depending on you, so do take care not to screw up.
+ not least because, as it says in the [[charter]] it will be your
+ responsibility to fix. that said, do not feel intimidated: ask for help
+ and advice, and you'll get it straight away.
+
+### Commit often
+
+* commit often. several times a day, and "git push" it. this is
+ collaboration. if something is left even overnight uncommitted and not
+ pushed so that other people can see it, it is a red flag. if you find
+ yourself thinking "i'll commit it when it's finished" or "i don't want to
+ commit something that people might criticise" *this is not collaboration*,
+ it is making yourself a bottleneck. pair-programming is supposed to help
+ avoid this kind of thing however pair-programming is difficult to organise
+ for remote collaborative libre projects (suggestions welcomed here)
+
+### Absolutely no auto-generated output
+
+* **do not commit autogenerated output**. write a shell script and commit
+ that, or add a Makefile to run the command that generates the output, but
+ **do not** add the actual output of **any** command to the repository.
+ ever. this is really important. even if it is a human-readable file
+ rather than a binary object file.
+ it is very common to add pdfs (the result of running latex2pdf) or configure.in (the result of running automake), they are an absolute nuisance and interfere hugely with git diffs, as well as waste hard disk space *and* network bandwidth. don't do it.
+
+### Write commands that do tasks and commit those
+
+* if the command needed to create any given autogenerated output is not
+ currently in the list of known project dependencies, first consult on
+ the list if it is okay to make that command become a hard dependency of
+ the project (hint: java, node.js php and .NET commands may cause delays
+ in response time due to other list participants laughing hysterically),
+ and after a decision is made, document the dependency and how its source
+ code is obtained and built (hence why it has to be discussed carefully)
+* if you find yourself repeating commands regularly, chances are high
+ that someone else will need to run them, too. clearly this includes
+ yourself, therefore, to make everyone's lives easier including your own,
+ put them into a .sh shell script (and/or a Makefile), commit them to
+ the repository and document them at the very minimum in the README,
+ INSTALL.txt or somewhere in a docs folder as appropriate. if unsure,
+ ask on the mailing list for advice.
+
+### Keep commits single-purpose
+
+* edit files making minimal *single purpose* modifications (even if
+ it involves multiple files. Good extreme example: globally changing
+ a function name across an entire codebase is one purpose, one commit,
+ yet hundreds of files. miss out one of those files, requiring multiple
+ commits, and it actually becomes a nuisance).
+
+### Run unit tests prior to commits
+
+* prior to committing make sure that relevant unit tests pass, or that
+ the change is a zero-impact addition (no unit tests fail at the minimum)
+
+### Do not break existing code
+
+* keep working code working **at all times**. find ways to ensure that this is the case. examples include writing alternative classes that replace existing functionality and adding runtime optiobs to select between old and new code.
+
+### Small commits with relevant commit message
+
+* commit no more than around 5 to 10 lines at a time, with a CLEAR message
+ (no "added this" or "changed that").
+* if as you write you find that the commit message involves a *list* of
+ changes or the word "and", then STOP. do not proceed: it is a "red flag"
+ that the commit has not been properly broken down into separate-purpose
+ commits. ask for advice on-list on how to proceed.
+
+### Exceptions to small commit: atomic single purpose commit
+
+* if it is essential to commit large amounts of code, ensure that it
+ is **not** in use **anywhere** by any other code. then make a *small*
+ (single purpose) followup commit which actually puts that code into use.
+
+this last rule is kinda flexible, because if you add the code *and* add
+the unit test *and* added it into the main code *and* ran all relevant
+unit tests on all cascade-impacted areas by that change, that's perfectly
+fine too. however if it is the end of a day, and you need to stop and
+do not have time to run the necessary unit tests, do *not* commit the
+change which integrates untested code: just commit the new code (only)
+and follow up the next day *after* running the full relevant unit tests.
+
+### Why such strict rules?