Voting starts in March for the Drupal Association Board election.
One of the great advantages of Drupal, compared to other frameworks used to build websites, is how quickly you can build new functions on your site. This is to a large extent explained by the fact that 90 percent of all functions can be provided by clicking and configuring modules, rather than writing code. In that light, it may seem strange that Drupal's community is putting a lot of effort into finding a good way for converting the configuration on a Drupal site into code to export the configuration.
There are several reasons why so many people are interested in saving configuration as code. One of the reasons is that it is easy to reuse functions that you have built. If you spent a day at clicking around in Drupal to build a photo gallery, you probably don't want to spend another day repeating this configuration the next time you want to build a similar gallery. If you could export your configuration and move the exported code to your new site, you could have the gallery set up in five minutes instead! Indeed, that would be useful.
But the most important motivation for exporting configuration into code is not that it could be copied. It is that it could be version controlled.
Professional software development have for many years been using version control systems as a part of the standard tools. These are tools used to record a certain state of the code being built, allowing you to view and revert to the code in different stages of the development. Version control systems could be compared to the saving functions in large computer games, allowing you to save your progress between every level (or right in the middle of it). If things go bad or you spent a lot of resources just to hit a dead end, which is hopefully more common in games than in development, you can return to these save points and start over.
Modern version control systems don't only allow developers to save the code they are working on themselves, but can also merge your own work with that of others, even if you are writing code within the same file. This means that you could be working with a specific feature in a project, while your colleagues are working with several other features and you could still share your progress with each other.
Version control has become such a natural part of software development that no professional coder would like to take on a project without version controlling her code. It allows you to keep track of the files you're working with and, maybe even more importantly, to transfer a recorded state of the code to test servers, staging servers and live servers. If, for some reason, it turns out that the latest updates on the live server have severe bugs, you can always revert to the previous version of the live code. You are saved.
Today there are many good systems for version control of code. The problem, though, is that configuration you make in Drupal is saved in the database and there are no good ways of version controlling database content.
In the old days, this lead to Drupal developers being forced to do point-and-click changes on the actual live site rather than a development copy of it. Even if you have done this over and over again on a test environment, something may go wrong. Maybe you make a mistake when you click. Maybe there are differences between the live and test server you didn't know about. Maybe someone else has been fiddling with the settings on the live Drupal site, without telling you. If you don't have version control, there is a risk that you can't undo your changes. There is no saved state to return to and no ctrl + z.
This is not the way it should be.