Are you a partner in a project with KDL? This set of Frequently Asked Questions might be useful to improve our collaboration.

If you don’t see your question answered or would like more clarification on an existing question please use the contact us form.

Pre project

What technologies does KDL support?

We host a variety of projects based around different technologies, Java web projects, TEI projects, and Python/Django projects. Since before its official establishment in 2015, we have been standardising our core technology stack and most of the recent and new projects are built with Python/Django, Foundation/Bootstrap for UI/UX, and Vue.js for certain frontend functionality. We are open to use other technologies as needed to fulfil project requirements; however, if we need to deviate from the core technical stack mentioned above, implications for sustainability should be assessed accordingly.

What kind of infrastructure does KDL use?

We have our own VMWare based infrastructure for hosting projects, but that may change in the future. Each project has at most 3 instances, dev (for development), staging and live. Each project has by default 3 instances, dev (for development), staging and live. We currently use Docker for local development and deployment.

We use mostly GitHub for source control, but we also have some projects in Gitlab, when we need more control over the CI pipeline or for private repositories. For continuous integration we use both Travis and Gitlab CI. The projects are deployed manually using a Fabric script. 

We make use of a startup configuration to start new projects to ensure they all follow the same guidelines.

How much lead time do I need to give KDL before submitting a new project?

KDL welcome new ideas for projects anytime (preferably via the contact us form; if these are funding proposals, KDL should be contacted as prospective partner 3-month prior to the deadline. This will allow us to discuss your idea and assess its feasibility.

We follow a 2-phase decision making process in which we decide if we can accept a new project to our portfolio. Firstly, we discuss all project proposals in our weekly project planning meeting to review if it fits within our research strategy, expertise and resource capacity. If we feel the project is a good fit, we’ll present the project to the Arts & Humanities Faculty for further discussion after which the final decision is made on our contribution to your project.

Project Planning meetings with Faculty are held every 6 weeks. This means you could have to wait several of weeks before we can confirm whether we can work on your project proposal. When you contact us, we will let you know when you can expect our answer so that you can plan for this in your submission timeline.

What can I expect KDL to produce for a funding application?

At the end of KDL feasibility assessment, partners receive a product quote defining methodological and technical requirements, and the nature of KDL involvement: solution architecture; development and management approaches; delivery plan; hosting and maintenance as well as archiving and sustainability plans; costs of KDL involvement including management and infrastructure charges as appropriate.

If agreed in advance, KDL also contributes extensively to data management plans or equivalent technical documentation required by the relevant funding scheme.

Why can't we contact KDL team members to propose projects directly?

New project ideas appear from a range of different sources, including one to one relationships developed between KDL team members and colleagues at King's College London and beyond. If you think someone in KDL might be particularly interested in your project idea feel free to drop them a line. The team is very busy, though, and managing our workload can be difficult. For that reason all project ideas, whether received via email or our contact us web form, are discussed at our weekly project planning meeting. This is the most important meeting the lab holds. We think through each project as a team, and work out how it aligns to our yearly goals, workflow, funding strategy, as well as the personal and technical interests of team members. In most cases it's easiest to send us an email ( or use the web form and open your idea to the whole team - that way everyone gets a chance to consider it.

Could you work from my existing datasets and material?

In principle we can but we would need to assess it. It would be extremely useful if you could prepare an inventory of your content and documentation about your datasets (e.g. columns in a spreadsheet, notational conventions) and the size and format of your data (e.g. JPG, CSV, XML, ...). We can start working from representative samples while the full dataset is being collected. However late changes in the structure or format of your data and delays in its delivery can disrupt the development schedule.

Do you have any tips on data collection?

KDL encourages the use of open data formats and standards.

The size and nature of the data, its diversity, provenance, licensing, compatibility of the input format with our software stack and existing workflows, as well as the degree of certainty, fuzziness, and interpretation in the data are all factors that affect the analysis KDL conducts and our recommendations in terms of data collection. During feasibility assessment (see below) as well as after a project started, in depth conversations with partners will inform data collection.

However, if a project hasn’t started yet, there are some general rules we could point to to follow when creating a dataset. While each research context requires bespoke analysis, here are some minimal tips KDL recommends you to follow:

  • Separate any fields you would like to conduct any analysis on (e.g. if surnames are a unit of analysis, make sure they are recorded in separate fields or columns distinct from first names). As a general rule, use one value per field; if multiple values, place them in separate fields or the comment field.
  • Be consistent with the format of the value in each field (e.g. dates); please use a clear convention for range of uncertainty and apply that consistently. Same applies to distinction between missing or ineligible values.
  • Minimise editorial interventions at collection stage unless agreed (e.g. don’t modernise names if later on the analysis might need to track back to the original place or person names, but provide separate field(s) for modernisation to fill in at a later stage or during data collection as appropriate).
  • If entity identification is relevant, create a field to start matching and facilitate merging (e.g. people with same names recorded as the same person or a different one).
  • Use notes and comments fields to record uncertainty or any comments on data collections that could be relevant to refine the data model later on (e.g. indication of possible names to merge or to separate).
  • Make sure all records link with enough precision to the location (as locus of occurrence) in the source material if relevant
  • If the plan is to analyse the dataset via the creation of maps, record geo-coordinates for known places if feasible.

See also:

Do you have any tips on data management?

The responsibility for the research data management plan stays primarily with the research partners but, as part of KDL's feasibility phase, we would like to review it and are happy to assist or provide guidance.

For partners based at King’s College London, the KCL guideline on research data management should be consulted.

See also:

Does KDL build marketing sites?

No. KDL does not build marketing sites for a project, a research output or an impact case study but we can guide colleagues towards other options for hosting.

Does KDL provide hosting and maintenance services for external providers?

No but if you’re unsure whether we can help, please contact at us at, and we’ll point you in the right direction.

Does KDL offers support for branding exercises?

No, unless this is part of the corporate design for a public facing digital product we developed. This summary of what KDL is and does could be useful.

Project start

What are the typical KDL roles in a project?

  • Project Manager:  main contact for process-oriented queries, team workflow planning across projects as well as first point fo escalation;
  • Analyst: main point of contact for any issues related to the development work for the project including bugs reporting; the analyst manages the scope and specification of the project requirements, coordinates the project review meetings with partners and all communication with the development team;
  • UI/UX Designer: responsible for coordinating, investigating and evaluating user requirements; delivering an intuitive experience using best practices and principles across all digital tools/products (e.g. public website, interactive visualisations);
  • Software Engineer (often referred to as Developer): coordinates and develops the project’s technical solution architecture from data modelling to storage solution, processing and public release;
  • Systems Manager: responsible for the infrastructure (where the project is hosted), from its technical  environment and setup of user accounts to server upgrades and other maintenance;
  • Director: point of escalation for any critical issues and concerns (e.g. HR and financial issues) and any general issues that require line management input;
  • Lab Manager: main contact for  financial queries and post-project issues e.g. extension of SLA, migration, archiving, copyright or data deposit

Below are some diagrams with more detailed descriptions that match our workflow to each role. For full role profiles see KDL roles profiles document.

Project Manager role

Project Manager role (MaDiH RSE training 2019)

Analyst role
Software Engineer role

Software Engineer role (MaDiH RSE training 2019)

UI/UX designer role

UI/UX Designer role (MaDiH RSE training 2019)

What is MoSCoW?

MoSCoW is a well known prioritisation technique which categorises requirements into four categories (Must have, Should have, Could have, and Won't have). MoSCoW is often used with timeboxing, where a deadline is fixed so that the focus must be on the most important requirements. All requirements are important, but they are prioritised to deliver the greatest and most immediate business benefits early. See for more details on the Agile DSDM use of MoSCoW. We will initially try to deliver all the Must have, Should have and Could have requirements but the Should and Could requirements will be the first to be removed if the delivery timescale looks threatened.

How will the project evolve?

See more about KDL process. The diagram below is a summary in a nutshell of phases and iterative development. See also “What is an SDLC?” and “What is an iterative process of development?”

KDL SDLC diagram

KDL Software Development Lifecycle

What is the kick off meeting?

The kick off is the meeting with all the key contacts of the project to define first increments of the project, ready for the first deployment. It takes place after the project start date. Review meetings are organised at all the key stages of the project.

How is communication between KDL team and the rest of the project team handled?

Once a project has started, regular review meetings are organised by KDL’s project analyst and associated documentation is kept up to date using project templates and the project and task management tool. Information is shared with partners to elicit feedback, initiate testing, and review progress.

Communication also takes place via email, outside regular review meetings. KDL project manager should be the main contact for process-oriented issues and financial queries while the KDL project analyst should be the main point of contact for any issues related to the development work. Please ensure the appropriate person or parties in the project team are contacted throughout the project. As we work with an iterative process, swift feedback after each increment is essential for the project to progress efficiently.

What is an iterative process of development?

We work using an iterative process which involves a process for arriving at a decision or a desired result by repeating rounds of analysis or a cycle of operations. This requires being open to changes as the process will likely lead to something completely different from the initial idea, yet a high quality, more functional and usable product aligned with requirements.

What is an SDLC?

SDLC stands for Software Development Lifecycle used to produce high quality software within budget and time constraints (you can read more about KDL SDLC and our project templates).

How is the editing workflow structured?

As summarised in the table below, KDL produces three environments for your project, each one running a slightly different copy of your website (or online resource):

  • Production (or Live): for your public facing site, which you can update on a regular basis;
  • Staging: for a private copy of the site where you and other partners can test new functionalities and editing your research database;
  • Development: used internally by KDL for development in progress or, occasionally, to give you a preview of upcoming features.

This staged set up improves the quality of your research output by ensuring that changes to your research data and the underlying software are first tested safely and then approved before being released to the general public.

Content type for each server: Column one has content type, other columns show the version of content available on each server
Dev Staging Production/Live
Software (e.g. search page, data visualisation, editorial tools) New software features are tested by KDL before being released to Staging New version of software is tested and approved by partners before being released Live
Research database (e.g. digital edition, tabular data, metadata) Research data can often be freely prepared and previewed by partners on staging before being released Live
Contextual content (e.g. blogs, news, about, home page or navigation menus) Partners can usually draft and publish their contextual content directly on the Live site using a Content Management System (e.g. Wagtail)

How do I log into the project non-public site?

Please let the project contact (normally the analyst) know title and affiliation of every partner who needs access to the editorial site. We will send them an email with a link to reset their password. That links expires rapidly and it takes us time to reissue it. Please make sure every member does it on time and takes note of their username and password.

How do I make sure some online resources are public and ready by a certain date?

If the project has an important deadline or the work you expect involves developing new features or type of contents, please give us enough notice (best to mention it at review meetings) so we can allocate enough time for support and testing.

How do I report a bug?

A good bug report contains the following information: browser & operating system, date & time, URL, complete sequence of actions on the web page to reproduce the bug, expected result vs actual result (screenshots also help). For further guidance see for example

To report a bug in your project site please contact the project analyst. To report a bug in any other site hosted by KDL please email us or use this report issue form.

What is change freeze?

The change freeze, sometimes also called code or feature freeze, occurs following the prioritisation of the final requirements for the project to allow for time to quality check, test and deliver a high quality solution. It is the stage where no more new features can be added as we are nearing the end of the project. An email will be sent out alerting partners about change freeze when 70-80% of the project is complete.

How should KDL be credited?

KDL contribution to scholarly outputs and other research products should be credited appropriately. KDL recommendations and practices are:

  • Partner’s responsibility: ‘About’ on project site page should include names of KDL staff who are closely involved with the project and the nature of their contribution (see list of KDL team members)’.
  • KDL’s responsibility: Website footer; ‘Technical overview’ page describing the technical development and design processes; project description page with KDL roles on KDL website (see examples on KDL site ‘Our work’); humans.txt file integrated with project website templates.
  • All: credit partner(s)/relevant KDL team members in publications connected to the project; include partner(s)/relevant KDL team members as co-authors when their contribution is substantial (e.g. KDL team members should be included as co-authors in conference papers, posters or articles describing the technical development or other aspects of the project they contributed to).

Post project

How is a project maintained after its completion?

KDL offers the option to maintaining the project under a costed Service Level Agreement (SLA). Usually the SLA is costed at pre-project phase and an email is sent out to request signatures prior to release. For SLA renewals partners are usually contacted 6-months before it expires. We offer agreements of variable durations depending on project age, infrastructure requirements, and PI preference but our standard SLA duration is five years. Typically, an SLA with KDL includes Support and Troubleshoot (e.g. issues with hosting and CMS) as well as periodic renewals and updates (e.g. hosting, licenses, frameworks, libraries).

Other options for archiving and sustainability are also possible and can be explored on a case by case basis (see more details on our archiving and sustainability approach).