[Labs-l] Some suggestions if you have no resolutions for 2016 yet

[Tim Landscheidt]

Hi,

the new year is just around the corner and you still have no
idea what to do with it?  Here are some suggestions for tool
developers and maintainers:

- Increase the [[bus factor]].  Add another (slightly inter-
  ested) developer to your tool.  This does not mean that
  they need to master the code from day #1, but that there
  is someone who feels authorised/obligated to fix a bug
  when you are on holiday/lost your password/have other com-
  mitments/etc.  Do not wait for their written request; ap-
  proach someone on your own.

- Publish the source.  All of it.  Publicly.  Make sure that
  there are no passwords in it.

- Write or review instructions on how to deploy your tool
  from the source.  Do you just need to copy the source to a
  directory?  Write it down.  Do you need to compile some-
  thing, convert data from this format to that, download
  stuff from here to there?  Write it down.  Who has a
  backup of the bot's wiki account's password?  Write it
  down.  This is not to guard against a Labs meltdown, but
  your memory loss.  It may be totally obvious to you /now/
  that you need to copy source repository A to directory X
  and B to Y, but in a year's time you will likely have no
  clue if the branch "new" or "bug-fix" is the correct one.
  Ask your newly-found co-maintainers if they understand the
  instructions.

- Fix your tool's warnings and errors.  All of them.  Your
  tool might still work if it encounters "undefined" or
  "uninitialized" variables, but a) these warnings slowly
  but surely fill up the storage space and (more impor-
  tantly) b) if in a year's time you or tomorrow your newly-
  found co-maintainer want (or rather need) to fix a bug,
  you will not know if those warnings are just background
  noise or indicators of a major malfunction.  If you want
  to output "" if a variable is not set or something simi-
  lar, don't use $variable and rely on PHP/Perl/etc.'s de-
  fault behaviour and your brain to remember that, don't
  write a comment in the code that the maintainer should ig-
  nore the warning, write code that just does not produce
  the warning.  It might take you a few seconds more to
  write "isset($variable) ? $variable : ''", but will save
  you much more time in the long run.  As a rule of thumb,
  your tool's error.log should not grow in normal opera-
  tions.  Ever.

- Advertise your tool.  You developed it to do X, so write a
  blog/village pump post demonstrating how you (or someone
  else) do X easier/faster/at all/etc. so that others can do
  X easier/faster/at all/etc. as well.  Users are great for
  debugging because they do things with your tool you didn't
  even dream of.  Or they have a suggestion on how to do X
  even easier/fastier.  Or they are interested in the soft-
  ware and you get a new co-maintainer without much of a
  search.

Happy hacking,
Tim