Needs assessment interview template

mentoring
Justin W. Flory
Interview template for UNICEF mentors when meeting a team for the first time.

This document is an interview template for needs assessments with UNICEF Venture Fund cohorts in Open Source induction calls. The needs assessment is a tool to collect background and context for each team’s experience and familiarity with open source. It also builds understanding for participation in existing open source communities. This template provides structure and guidance on what to ask to any team at the beginning of an Open Source Mentorship program.

1. Your current situation πŸ”—

This section helps us understand where each team is at the moment.

  1. What current milestones is the team working towards? Can be development and/or business.

  2. How much of your project source code is already on a git hosting platform, e.g. GitHub / GitLab? Either public or private is okay.

  3. Based on what you know about Open Source today, what challenges or concerns do you have about Open Source specifically?

  4. Is there any prior Open Source development experience on your team?

  5. Do you have an existing user community?

  6. Does your project source code extend or make improvements to an already-existing Open Source project? (a.k.a. upstream)

2. Project management πŸ”—

These questions explore project management and any tools or processes that are already in place.

  1. Is your team fully remote, partially remote, or all in-person?

  2. Does your team use a project management methodology? (e.g. agile, scrum, waterfall)

  3. How often does your development team meet?

  4. What project management tools are you already using? (e.g. Trello, Asana, GitHub Projects, JIRA, etc.)

3. Development best practices πŸ”—

These questions explore development best practices and how the team produces source code. It covers a range of periphery activities around development, such as unit testing, static analysis, automation, and more. The goal is to understand where the team is currently, and where Open Source Mentorship will focus initially. This intersects with other topics like Continuous Integration.

3.1. Testing πŸ”—

  1. Does the current project source code have ANY unit, functional, and/or integration tests?

    1. If yes: Estimate a percentage of how much code is currently tested.

    2. If yes: What testing frameworks are used?

3.2. Tooling πŸ”—

  1. Do you already use any static analysis or code health-checking tools?

  2. Are any automation tools already in use? (e.g. Ansible, Chef, Docker containers, GitHub Actions, etc.)

3.3. Workflow πŸ”—

  1. Is any developer on the team able to add code directly to the product, or are contributions peer-reviewed before merging?

4. Documentation πŸ”—

These questions explore documentation culture. Some teams may do this better than others at the start, but the goal is to establish a baseline.

  1. READMEs: Do core repositories have a README file that explains what the repo is, how it works at a high-level, and how that single repo integrates into your overall product?

  2. Developer documentation: Is any documentation already written about how to set up a local development environment for any of your projects? Does not have to be stored in git.

5. Vision πŸ”—

These questions explore Open Source vision. It gets the team thinking about where we are going and what the next steps might be in reaching that vision.

  1. What does success look like in a world in 12 months when you have launched your Open Source projects?

  2. Name one thing that needs to change today on your team in order to accomplish this vision. (suggestion: everyone on the call should answer this one!)

6. Archived questions πŸ”—

These questions were once included in the needs assessment, but are no longer asked. This is because the answers to these questions are either documented elsewhere, or they are better answered asynchronously.

  1. What is your product elevator pitch? (i.e. describe project in 2-3 sentences)
  2. If you could grade how well your team does open source, what grade would you give yourself and why?
  3. Do you hold daily or weekly meetings to track progress with the core development team?
  4. Did you receive peer reviews on your code base in the last three months by someone outside of your organization?