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

[Ricordisamoa]

Agree with all of them! Please post the list to a prominent page.

Il 29/12/2015 05:57, Tim Landscheidt ha scritto:
> 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
>
>
> _______________________________________________
> Labs-l mailing list
> Labs-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/labs-l