Strategy for Genuki development

Introduction

At the time of writing (April 2019) Genuki has been in existence for over 25 years.  During that period, genealogical and family history information has been collected and entered into the system covering all counties and places in England, Wales, Scotland, Northern Ireland, Republic of Ireland, and the Channel Islands.

Genuki has always been run by a group of volunteers called "maintainers", each of whom normally maintain one or more counties.

For the first 20+ years of Genuki's existence, the system consisted almost entirely of static html pages created by each of the county maintainers.  Approximately 5 years ago the decision was taken to move Genuki onto a Content Management System (CMS).  The software chosen for this development was Drupal.  The effort required to migrate Genuki from HTML pages into Drupal was huge.  The conversion project took 2-3 years and was managed by a small project team of 5 people (Brian Randall, Phil Stringer, Gareth Hicks, David McFarlane and Ken Greenslade).

Genuki has always been governed by a group of Trustees.  In 2018, once the conversion to Drupal was complete, in addition to the Genuki Trustees, a small Executive Team was created to run the day-to-day operations and to continually develop the system.

Purpose of this document

As described above, the Genuki system has continued to evolve over the past few years.  Using Drupal as our CMS, it has been possible to add many new features to the system.  However, the general consensus amongst the members of the Executive Team is that a proper documented strategy is required to articulate how Genuki should be developed over the next few years.

This document attempts to define a strategy for Genuki for the next 2-3 years covering the following areas:

• the information that is held in the system (Genuki's "content")
• the functionality provided by the system
• the development of the Genuki technical infrastructure
• the acquisition and retention of maintainers
• the governance of Genuki
• documentation of Genuki
• outstanding issues from the conversion of Genuki-1 into Genuki-2 in Drupal

The information held in Genuki

The Genuki system current holds 5 main types ("content types") of information:

• Place pages - every town and parish within every county has a separate page.  Information is categorised and displayed in 70+ topics.
• Topic pages - these pages hold information relating to a single topic for a single place, and can be automatically incorporated into Place pages
• Plain pages - these are typically miscellaneous pages holding additional information that is not stored on the main Place page
• Church pages - every church, chapel and cemetery in the whole of UK and Ireland should have an individual page.  These pages can be used to store information for a specific church, and again the information is stored in a number of topics
• Gazetteer pages - every place (ie. City, Town, Village, Hamlet, etc) in UK and Ireland should have a separate gazetteer page showing the location of the place

In each of the above content types there is a wide disparity between counties.  Although Genuki has been around for 25+ years, some counties are highly developed and other counties are barely started. 

Also, there is an understandable feeling that Genuki should have a common or consistent look to it across all its countries and counties and this is reinforced through Drupal and its rigid template structure. However we should recognise that there are some facets where total consistency is not achievable and the status quo and preferences of individual maintainers are supreme. An example is the Church Database OR place node topic issue. In several Welsh counties the Church History and Church Records topic fields are stuffed with data whereas the individual church nodes have the bare minimum. The latter are clearly designed to hold all the data for churches and chapels but don’t and never will. From the maintainer's perspective, a rigid consistency in all things is not desirable or achievable and should not form part of any global strategy.

Proposed strategy:  It is proposed that for the next 2-3 years we should concentrate on getting all counties to a similar level of detail in each of the above content types.  This would obviously require flexibility amongst maintainers to work on other counties for a period to get the information up to the required standard.  Before any of this work could begin, it is recommended that we specify the required standard for each content type.  For example, which type of places should be included in the gazetteer and which should not ? Or what is the basic information required to be held again each church entry ?

To assist with this work, it may be necessary to define some status and/or exception reports showing progress against the required standard.

NB.  The above strategy assumes that there is no requirement for a completely new type of content to be held in Genuki.  Should such a new requirement be identified as part of this exercise, then this should obviously be taken into account when defining the strategy.

The functionality provided by the Genuki system

Over the last 3-4 years a significant amount of features and report/queries have been added to the Drupal system.  For example, over the last 6 months significant effort has been added to the Genuki mapping features to enable the parish boundary to be shown on every Place page.

Proposed strategy:  It is proposed that a prioritised list of new features is drawn up.  There are already many outstanding requests already logged as support tickets.  The group of Genuki maintainers should be given the chance to input into this process.

The development of the Genuki technical infrastructure

Currently the Genuki service runs on a web server hosted by the company Mythic Beasts.  The web server is running a Linux Debian operating system.  The web server itself is running Apache v2.4.  The CMS software is running Drupal 7 based on PHP 5.6  (NB. PHP was recently upgraded to PHP 7.2).

The approach from Genuki over the years is to use stable, tried and tested, versions of software, rather than use "leading edge" versions of software as soon as they are released.

The Drupal organisation released Drupal 8 in 2015 (ie. 4 years ago) and have recently announced that Drupal 9 will be released in 2020.  It is Drupal's normal practice to only support the 2 latest  major versions of its software, so when Drupal 9 is released in 2020, Drupal 7 will become no longer supported and will soon reach its "end of life".  It is general accepted within the Drupal community that the move from Drupal 7 to Drupal 8 is a significant change, whereas the move from Drupal 8 to Drupal 9 will be relatively straight forward.  The reasons for this are numerous, technically complicated and beyond the scope of this strategy document (For more information, please speak to Phil or Ken).

Finally, Genuki’s existence is now closely intertwined with Drupal, with its need for constant upgrading which requires technical expertise way beyond the average maintainer. We have to fully appreciate that Drupal has brought with it an even greater reliance on an exceedingly small technical team.

Proposed Strategy:  It is recommended that Genuki move from Drupal 7 to Drupal 8 by the end of 2020, so that we are no longer using Drupal 7 should it becomes unsupported in 2020.

We must be 100% convinced about any potential future developments, however attractive technically, which would require maintainers at large to undertake ‘work’ beyond their routine responsibilities such as link checking and content enhancement.

Given the reliance on an exceedingly small technical team, we should give some thought to a scenario where either or both Phil and Ken are unable/unwilling to carry on at their current level of commitment. A ‘head in the sand’ approach works fine - right up to the day it doesn’t.

Acquisition and retention of maintainers

Over the last two years it was recognised that Genuki was struggling to recruit new maintainers.  Also, unfortunately, we continue to lose existing maintainers, often for no apparent reason.  Therefore, the decision was made to recruit a Volunteer Co-ordinator (Peggi Rodgers).  This has worked well and has resulted in the recruitment of several new volunteers.

However, the Genuki system is big and complicated.  It is often overwhelming for new recruits, and some attempts have been made over the last few months to develop training materials for new recruits.

Although we have recruited Peggi to find new maintainers and get them started, this role excluded encouraging existing maintainers. At the moment they are in effect abandoned.  That does not encourage them develop their pages and is likely to be one reason that some give up.

There are two other factors which have a bearing on maintainer retention, both currently totally absent. The first is leadership which the Genuki Executive Team must provide.  Secondly, maintainers need to ‘take ownership’ of genuki beyond their own counties. The obvious way to bring that about is to involve them in pan-Genuki activities thus fostering a ‘sense of belonging’ which is why the Drupal conversion team are still working together.

PS. Since writing the above I have analysed the User Logins and find that 27 maintainers have logged in this year, 19 in 2018 and 12 before that. The latter group  maybe a lost cause but the 2018 group includes  several familiar names who we really can’t afford to lose touch with. We have to get to grips with this issue urgently.

Proposed Strategy:  This draft strategy document should be distributed to all maintainers to obtain their input and feedback.

Further effort should be given to develop new training material for new and existing experienced maintainers.  Also, further work should be done which work should be offered to new recruits as soon as they start, as opposed to other responsibilities that can be allocated once they are more experienced.

For existing maintainers, we should try and get somebody in place to regularly keep in touch with the maintainers, to encourage them, and suggest improvements that can be done and ways to make the job easier.

Consider setting up a number of small project teams of maintainers to work on initiatives beyond their own counties.  An example of that might be labour intensive low-tech projects such as Kain boundary drawing where there is still much to do.

We should consider each of the following:

• improved quality control - some more systematic means of identifying sections of Genuki that need to be concentrated on
• investigating possible partnerships - identifying/creating ways in which we can make cooperation with Genuki an interesting and attractive proposition for people who currently are pursuing related efforts quite separately, e.g. one-place studies sites, individual FHS sites, etc.
• publicity for Genuki, so that it resumes it’s place in typical general published accounts on how to get started with, and to progress in, genealogy
• publicity (via a sequence of articles and announcements) for the technical improvements that have been made in Genuki - the Drupal conversion saga and the ensuing benefits, the gazetteer improvements, the map facilities, etc.
• an aggressive recruitment campaign - possibly via a set of targetted messages aimed at particular regional mailing lists and family history societies that correspond to weak parts of Genuki.  The above list no doubt could be greatly improved if we put our collective minds to it - but it is our belief that the single best thing we could do is recruit one or two energetic individuals (possibly, but improbably, from among the present maintainers) who would like the challenge of dealing with this whole issue, i.e. we need some more managers/organisers, not just maintainers, so that we can getter more and better maintainers, and get more out of them.
• revitalise the maintainers list as the main conduit for raising/communicating ‘everything Genuki’. No need to invent something else for the job, it will do for now. People need to be encouraged to ask their questions on it, keep it light hearted.  Are there list archives that are easily accessible?

The governance of Genuki

Over the course of the last 2-3 years there was much discussion between the Genuki Conversion Team and the Genuki Trustees.  This discussion eventually led to the establishment of an small Executive Team (Ken Greenslade, Phil Stringer, Brian Randall).

Proposed Strategy:  It is proposed that the existing Trustees / Executive Team governance model is allowed to run for a year or two, before deciding whether further improvements should be made.

Documentation of Genuki

GENUKI documentation tends to be largely plain text, excessively wordy due to the need to cover all situations and avoid ambiguity, with few illustrations, no doubt because no special hardware or skills are required to produce it in this way. It is often produced to meet a particular panic, and tends to go out of date very quickly, overtaken by fast-moving developments. It is also poorly structured and maintained, with many pages now obsolete or redundant.

We should be looking for something easier to develop and use, and be self-indexing.

Proposed Strategy:  With a conversion to Drupal 8 now in sight, we could take the opportunity produce a new, clean and simplified set of documentation as the new system is being developed, to be launched in parallel with the new system itself.  We should use more illustrations, using defocused generic page images to explain things, to focus the reader's attention on the main points, and minimising the need for constant updates. Snagit is one text and image text and image capture tool that can be used for this (free tutorials are available on-line). Another approach could be to adopt Drupal.org's own approach, with related documents listed in a right-hand sidebar. Again, we have already seen suitable short videos on particular topics have to be useful.

Completion of conversion from Genuki-1

There are still odd bits of the site that still use Genuki-1 to provide the information, most of it being Phil's responsibility and that needs clearing up. They are:

• Church database search. The very first bit of the search from the menu link still uses the genuki-1 gazetteer to look up the place name to get a lat/lon before it then uses drupal code to do the searching.
• We have functionality to link Family History Societies to places using the genuki-1 gazetteer entries and provide links to the societies via the place nodes. There is also draw maps showing the areas the societies cover. This development was also being used as a model  for providing information about other organisations such as Poor Law unions, Civil Registration districts etc. I think it would be best to continue deferring work on this until we have a drupal 8 system in place.
• Church records information. When looking for church records the information for an individual church can come from multiple sources. A record office may hold the original registers, a group such as the Lancashire Parish Register Society may have transcribed and published them, and an FHS may have published the MIs. Now that information can of course be added individually to each church node, but it requires a lot of effort from the maintainer and it isn't easy to learn about updates. So we have system in place where we can have a csv file for each institution holding the records which is used to automatically add details to the relevant church nodes. So an FHS could have a single list of its church publications which they can periodically update and pass on to use to automatically update the individual church nodes. This currently uses genuki-1 code. Work on this should again be kept on hold until we are using drupal 8 as a redesign is likely and choice of how to hold the data.

Proposed Strategy:  It is proposed that all the outstanding element of the Genuki-1 conversion are resolved during, or shortly after the move to Drupal 8.

*****