The week of the 4th to 8th of June 2018 was the 11th annual Geonetwork Codesprint in Bolsena, coordinated by GeoCat. As in previous years, the Geonetwork developer team took over an ex-convent, just outside the small town of Bolsena, on the side of the lake of the same name, about 135km north of Rome.
View Larger Map
At Astun we've always had a firm belief in contributing back something to the open source software that we use, be that by sponsoring or providing enhancements, fixing bugs, or getting involved with conferences and hackathons. Due to the work we've been doing supporting and extending Geonetwork for our local Government INSPIRE metadata portal, for the Scottish Spatial Data Infrastructure portal, and with DEFRA, this event seemed like a good opportunity to meet the core developers face to face, to learn something new, and perhaps assist with some development.
I went along with no fixed expectations of what would be involved, or what I could contribute. I consider myself to be a non-coder, although I know my way around the Geonetwork repository on GitHub well enough to compile and deploy the code from source and to debug issues. Furthermore, these days the Geonetwork code is only part of the story! The metadata is stored in a back-end database, generally PostgreSQL, and then the search results are indexed in ElasticSearch, with Kibana providing dashboarding capabilities (more on this later).
So what does a non-coder do at a codesprint? Plenty, as it happens!
Day one was mainly about orientation. There was a "state of the nation" talk going through the metrics of the project (the number of contributors, the number of bugs reported and fixed, and so on). This was followed by some ideas as to what might be achievable in the week. These basically broke down to the following over-arching themes:
Over the next few days we worked through these main themes, punctuated by lovely home-cooked meals sat outside in the convent garden, some multi-lingual karaoke, an afternoon wandering through the medieval streets of Bolsena, and an evening at the National Museum in Rome.
The move to ElasticSearch was a big step in Geonetwork 3.4, and has felt to me like a black art. There's a lot of new technology to learn (shards, index patterns, mappings, clusters, nodes...) and a new syntax for querying. I was concerned that end-users might struggle to reproduce queries that they had created in previous versions of the software without a lot of additional support. So while the developers were working on the code, I created some documentation on ElasticSearch for new Geonetwork admins, and also investigated a plugin that provides a more familiar SQL interface to the index. The latter needs a lot of work to be useful, I think, but it could be handy for people getting used to the new technology, like me for example!
Refactoring the release and branching workflow sounds very dull, but was a very important step in improving the quality and sustainability of releases. In a nutshell it means that new features are introduced in new major releases of the code rather than appearing unannounced in a patch. This required a lot of work on the part of the developers, and it's not something I could really help with, other than by supporting it as a Really Good Idea.
One thing I was very excited to see was the new script for generating a metadata schema or profile.
Bug squashing and pull request acceptance was fun, and rather satisfying. Many bugs had been superseded by later versions of the code (including some of my own), or had not been commented on for over a year. These could all be closed. Others needed tagging to ensure they were matched to the correct release, or needed more information before they could be reproduced. I was made a contributor to the project so I could assist with this. I have plans to start creating bugs for unfinished documentation now I can tag them as such. Documentation bugs are a really easy way for beginners to contribute to a project, as well as being extremely valuable to the developers.
All in all, it was a great week, and I would definitely argue that non-coders can contribute to, and get a lot out of codesprints. While we worked hard, there's something about being in lovely surroundings, with nice weather and good company to make it feel a lot less like work!
View Larger Map
At Astun we've always had a firm belief in contributing back something to the open source software that we use, be that by sponsoring or providing enhancements, fixing bugs, or getting involved with conferences and hackathons. Due to the work we've been doing supporting and extending Geonetwork for our local Government INSPIRE metadata portal, for the Scottish Spatial Data Infrastructure portal, and with DEFRA, this event seemed like a good opportunity to meet the core developers face to face, to learn something new, and perhaps assist with some development.
I went along with no fixed expectations of what would be involved, or what I could contribute. I consider myself to be a non-coder, although I know my way around the Geonetwork repository on GitHub well enough to compile and deploy the code from source and to debug issues. Furthermore, these days the Geonetwork code is only part of the story! The metadata is stored in a back-end database, generally PostgreSQL, and then the search results are indexed in ElasticSearch, with Kibana providing dashboarding capabilities (more on this later).
So what does a non-coder do at a codesprint? Plenty, as it happens!
Day one was mainly about orientation. There was a "state of the nation" talk going through the metrics of the project (the number of contributors, the number of bugs reported and fixed, and so on). This was followed by some ideas as to what might be achievable in the week. These basically broke down to the following over-arching themes:
- Remove the historic dependencies on Lucene for searching and move entirely over to ElasticSearch
- Refactor the release and branching workflow in the Github repository so that new features were added to the correct (future) release and not to the current stable branch
- Test a new script for generating new metadata schemas or profiles
- Squash as many bugs and merge as many pull requests as possible!
Over the next few days we worked through these main themes, punctuated by lovely home-cooked meals sat outside in the convent garden, some multi-lingual karaoke, an afternoon wandering through the medieval streets of Bolsena, and an evening at the National Museum in Rome.
The move to ElasticSearch was a big step in Geonetwork 3.4, and has felt to me like a black art. There's a lot of new technology to learn (shards, index patterns, mappings, clusters, nodes...) and a new syntax for querying. I was concerned that end-users might struggle to reproduce queries that they had created in previous versions of the software without a lot of additional support. So while the developers were working on the code, I created some documentation on ElasticSearch for new Geonetwork admins, and also investigated a plugin that provides a more familiar SQL interface to the index. The latter needs a lot of work to be useful, I think, but it could be handy for people getting used to the new technology, like me for example!
Refactoring the release and branching workflow sounds very dull, but was a very important step in improving the quality and sustainability of releases. In a nutshell it means that new features are introduced in new major releases of the code rather than appearing unannounced in a patch. This required a lot of work on the part of the developers, and it's not something I could really help with, other than by supporting it as a Really Good Idea.
One thing I was very excited to see was the new script for generating a metadata schema or profile.
At Astun we've contributed towards the development of the Gemini 2.2 metadata profile for Geonetwork, and have also built an extended metadata profile for the Environment Agency to allow them to store some additional metadata elements, such as an Approval for Access code, and also to include additional validation rules. This process is quite time-consuming, so being able to automate at least the basic process will be extremely handy, particularly when we come to work on a Gemini 2.3 plugin later this year.José showing the new automatic wizardly schema generator for #GeoNetwork #Bolsena #foss4g @OSGeo @geocat_bv pic.twitter.com/AlN0chz2Oe— María Arias de Reyna (@delawen) June 6, 2018
Bug squashing and pull request acceptance was fun, and rather satisfying. Many bugs had been superseded by later versions of the code (including some of my own), or had not been commented on for over a year. These could all be closed. Others needed tagging to ensure they were matched to the correct release, or needed more information before they could be reproduced. I was made a contributor to the project so I could assist with this. I have plans to start creating bugs for unfinished documentation now I can tag them as such. Documentation bugs are a really easy way for beginners to contribute to a project, as well as being extremely valuable to the developers.
All in all, it was a great week, and I would definitely argue that non-coders can contribute to, and get a lot out of codesprints. While we worked hard, there's something about being in lovely surroundings, with nice weather and good company to make it feel a lot less like work!
Comments
Post a Comment