This document is a template to collect the data LFN thinks are relevant to LFN Project health. Projects will copy this template and instantiate it with their data as a part of applying for lifecycle state transitions or induction into the LFN.
Click the "..." in the upper right hand corner of this page. Click "Copy". Choose "Project Proposals". Rename the title to your Project
If the project has instantiated this template before, they are welcome to start from that base and update it with any new information. Be sure that the data requested by the primary copy of the Project Data Template has not changed.
These instructions should be removed from the instantiated template.
This slide is an overview of the fundamental information about your project.
Project Name: Please fill in the official name of the project. This is the name that will be used in all official documentation and communication.
Project Creation Date: Enter the date when the project was officially started or initiated.
Project License: Specify the license under which your project is distributed. Examples include Apache 2.0, MIT, GPL, etc. If you have multiple licenses, please list them all.
Contributing Organizations: Here, you should list all organizations that are actively contributing to the project. This includes companies, academic institutions, non-profits, etc.
This slide provides information about the resources that your project has in place to foster communication, collaboration, and transparency in your community.
This slide offers information about how your project is organized and managed, and how decisions are made.
Project Roles: Briefly describe the various roles within your project (e.g., Project Lead, Maintainer, Contributor, etc.) and what responsibilities each role carries.
How people come to fill project roles: Outline the process by which individuals are chosen or elected to fill specific roles within your project. This might involve a vote by existing members, an application process, or some other method.
How people are removed from project roles: Detail the procedure for removing individuals from their roles, whether due to inactivity, misconduct, or some other reason.
Who currently fills all project roles: Provide a list of the individuals who currently occupy each role within your project.
How disputes are definitively resolved: Explain the system for resolving disputes within your project. Typically, this is done by a majority vote among certain project members.
How governance evolves over time: Describe how your project's governance structure may change and adapt over time. This might involve the creation of new roles or the modification of existing ones.
What is the top-level technical decision-making body for the project, analogous to a TSC, to which the TAC should look for interfaces? Provide information about the primary technical decision-making body of your project. This is typically a Technical Steering Committee (TSC) or something similar.
Remember, this slide should provide a clear overview of how your project's governance operates. The clearer this is, the easier it will be for newcomers to understand how they can participate and contribute to the project.
This slide is your opportunity to clearly define the specific problem your project aims to solve, as well as the use case scenarios your project addresses. This will help the TAC understand the context and importance of your project. Here are some pointers to guide you through the process:
Problem Statement: This is where you define the problem that your project is designed to solve. Be specific about what the problem is, who it affects, and what implications it has. The problem statement should be succinct, focused, and clear.
Use Case Scenarios: List and describe typical situations where your project would be applied. Who are the users? What are their goals? What tasks are they performing, and how does your project assist in accomplishing these tasks? Be sure to highlight how your project is unique in addressing these needs.
Remember, clarity is key. Provide enough detail to comprehensively view the problem and use case scenarios, but strive to keep your language simple and direct.
This slide is dedicated to presenting your project's architecture. Your aim here is to give the TAC a clear understanding of how your project is structured and how its various components interact. Below are some guidelines to assist you:
High-Level Overview: Provide a general description of your project's architecture. This can include the guiding principles behind its design, the architectural style or pattern it follows (e.g., microservices, event-driven, layered), and any notable characteristics.
Component Diagram: Include a diagram illustrating the main components of your project and their interactions. This visual representation can greatly enhance understanding. Be sure to label all parts of the diagram and provide a brief description of each component's function.
Key Interfaces & Dependencies: Describe the critical interfaces within your project and any external dependencies.
Data Flow: If applicable, briefly explain how data flows within your system. This can be included in your component diagram or described separately.
Future Evolution: Briefly outline any planned or potential changes to your project's architecture.
Remember, your goal here is to provide a clear, concise overview that's understandable even to those who may not be familiar with every technical detail.
In this slide, you are expected to present an overview of the tools your project utilizes for its infrastructure. These are crucial to your project's operation, allowing your team to collaborate effectively, track progress, handle issues, and maintain high-quality standards.
When filling out this slide, please provide the following details:
Wiki: Share a link to your project's wiki page, if applicable. This is where you can house essential project documentation, updates, and information.
Code Repositories: Include a link to where your code is hosted. This could be a platform like GitHub, GitLab, or BitBucket.
Bug Tracking: Specify the tool you're using to track bugs and issues, such as JIRA, GitHub Issues, or Bugzilla. Include a link to your project's specific bug tracking page or system.
Code Review: Indicate what system or tool you're using for code reviews. This could be Gerrit, GitHub PRs, etc. Don't forget to provide a link to where these reviews take place.
Documentation: Share where the project's technical and user documentation is stored and accessible. This could be on a dedicated website, within the code repository, or elsewhere.
CI/CD Tooling: Specify the continuous integration/continuous deployment (CI/CD) tooling you use. This could be Jenkins, GitLab CI, GitHub Actions, etc.
Collaboration tools: Mention any tools you use for project communication and collaboration. This could include mailing lists, forums, chat platforms (e.g., Slack, Teams), video conferencing tools, etc.
Remember, it's not just about listing the tools—you should provide direct links and briefly explain how each tool contributes to your project's infrastructure and workflow.
In this final slide, you are to provide an overview of your project's future trajectory. The roadmap should highlight the key milestones and deliverables your project aims to achieve in the upcoming quarters or years. Here's a guide to help you fill it out:
Near-Term Objectives: List your immediate goals for the project. What are the critical tasks or features that you aim to complete in the next few months? Ensure these objectives are clearly defined, achievable, and align with the overall project vision.
Long-Term Objectives: Detail the broader, strategic goals for your project. Where do you see your project heading in a year or more? Long-term objectives should be ambitious, yet attainable, driving the project towards continuous growth and innovation.
Key Milestones: Highlight the significant events or checkpoints in your project timeline. These could include anticipated release dates, feature completion, important meetings, or any other noteworthy occurrences.
Risks & Challenges: Identify potential obstacles that could impact the roadmap. Discussing these openly helps to prepare the team and stakeholders for any contingency and fosters a proactive approach to problem-solving.
Timeline: Provide a visual representation or description of your roadmap's timeline. This will give your audience a clear understanding of your project's path and the order in which you expect to achieve your objectives.
Remember, the roadmap is a strategic document that guides your project. It's okay if it changes over time; the aim is to provide a clear, ambitious, yet realistic, direction for your project's future.
Explanations of domain-specific vocabulary.
.. todo:: Look into using special rst to make these definitions into tooltips
.. todo:: Consider extracting this to a stand-along file so can reuse elsewhere