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 [email protected] https://lists.wikimedia.org/mailman/listinfo/labs-l
_______________________________________________ Labs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/labs-l
