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.
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.
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 contribute 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 interests of team members. In most cases it's easiest to send us an email (email@example.com) or use the web form and open your idea to the whole team - that way everyone gets a chance to think about whether they'd like to be involved in it.
Could you work from my existing datasets and material?
In principle we can but we would need to assess based on data formats. 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 the 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, 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 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 field 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 original place or person names but provide separate field 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.
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 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.
- 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.
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 firstname.lastname@example.org, 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.
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 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.
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?”
How is communication between KDL team and the rest of the project team handled?
Apart from regular review meetings, most communication will take place via email (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 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.
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).
How do I log into the project non-public site?
Please let us know the full name, 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 https://blog.testlodge.com/how-to-write-a-good-bug-report/
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).
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).