I need to create a simple and stupid game for myself

Antiyoy is a very simple game in which I know how to win. Sometimes it takes a few experiments, but I know how to beat the game and doing so makes me feel good.

Unlike search engine optimization, or even just the success of a single blog post, here I know the outcome and I don't need to invest a lot of brain power to have success.

Probably something to do with Dopamine.

That's why I have spent, or more correctly, wasted an embarrassingly high number of hours on this game. 

Time to change!

It is time to create some other game for myself that is also very simple and where I know I can win. Or at least in most of the cases I win.

As I understand these games are even more addictive if you don't always win.

This game however needs to be something that won't be a total waste of time playing.  Something that will give me the good feeling and might move the world forward a bit.

I am still unclear about it, but I think I found something.

The game is this:

Find an Open Source project and make some relatively easy improvements to it.

Actually it is to find many Open Source projects and make some relatively easy improvements to all of them.

It can be done for any Open Source project and apparently, without even noticing it, I've already started to play it for projects in Perl and in Python.

For Perl I started to measure how many CPAN modules have link to their VCS and how many use CI.

For Python I built a whole web site collecting meta-data about Python projects.

So the game is now the following:

For Perl

  1. Find a CPAN module without link to VCS. Try to locate the VCS by looking at the other modules of the same person. If found then send a pull-request base on my blog how to add VCS link to CPAN modules. If I cannot find the repository then contact the author and ask them if they have a public VCS and if they would like to link to it. In some cases this is successful in other cases the author either does not have a public VCS or is not interested in making it easy to find it. It is strange to me, but well, I can't always win in this game.
  2. Find a CPAN module that does not use any Continuous Integration system (CI). (I need the VCS link to find the repo.)
  3. The CPAN::Digger project helps me with the above two.

    4. For Python

    I have not really played this yet, but let me write down the steps. They are quite similar to one for Perl, but I use the PyDigger project to get the links.

    1. There are so many Python packages with link to VCS, but without CI system, that I think for a long time I can primarily focus on locating these packages and either asking them if they are interested in a Pull-request for a CI system, or sending the pull-request right away.
    2. Later on I can start locating packages without a link to their VCS and then contacting the authors.

    Proxies to Quality measurements

    Here the idea is to come up with various metrics for quality of code and various ways to measure these.

    Then measure the current status of the various open source projects and then measure the progress.

    The basics that are more administrative than actual quality are the ones mentioned above. Having a VCS link and CI set up. There are few other interesting fields in the META-data of the projects.

    The others can be

    • Linter results (Perl::Critic, PEP8 and Flake8 for Python
    • Test failure frequency
    • Well formatting of code (tidy, beautify, etc.)
    • Test Coverage with all the caveats
    • Cyclomatic complexity
    • Number of open tickets, time to resolve tickets. (Is this really relevant here?)

    Dave Cross had a presentation about some related topics: Measuring the Quality of your Perl Code but I've also written about the subject when thinking about Measuring confidence level in an application.

    The name of the game

    For no better idea, let me call it the CI-game for now.