What project partners might want to know about KDL

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 using 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.

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.

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.

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.

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 (kdl-info@kcl.ac.uk) or use the web form and open your idea to the whole team - that way everyone gets a chance to consider it.

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.

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:

• W3C Data on the Web Best Practices

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:

• FAIR Guiding Principles for scientific data management and stewardship
• Borer et al. Some Simple Guidelines for Effective Data Management The Bulletin of the Ecological Society of America 90.2 (2009): 205-214. 

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.

No but if you’re unsure whether we can help, please contact at us at kdl-info@kcl.ac.uk, and we’ll point you in the right direction.

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 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.

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 https://www.agilebusiness.org/content/moscow-prioritisation 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.

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?”

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.

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).

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.

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 https://blog.testlodge.com/how-to-write-a-good-bug-report/

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.

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).