(no commit message)

diff --git a/HDL_workflow.mdwn b/HDL_workflow.mdwn
index 011eb3b6bd985586f6585f36d9e31479e31ff9dc..98e4bf60181d0d7142ab06acde52b66933163bfe 100644 (file)
--- a/HDL_workflow.mdwn
+++ b/HDL_workflow.mdwn
@@ -186,6 +186,7 @@ for actual code development:
 
 * 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).
 * 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. several times a day, and "git push" it.  this is collaboration. if something is left evrn 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 over remote collaborative libre projects.
 * **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.
 * 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.