docs/lifecycle/project_data_template.rst

   1 *********************
   2 Project Data Template
   3 *********************
   4
   5 Instructions
   6 ------------
   7
   8 This document is a template to collect the data LFN thinks are relevant to LFN
   9 Project health. Projects will copy this template and instantiate it with their
  10 data as a part applying for lifecycle state transitions.
  11
  12   mkdir -p <relevant lifecycle transition dir>/<project name>/
  13   cp project_data_template.rst !$/project_data.rst
  14
  15 If the project has instantiated this template before they are welcome to start
  16 from that base and update it with any new information. Be sure that the data
  17 requested by the primary copy of the Project Data Template has not changed.
  18
  19 These instructions should be removed from the instantiated template.
  20
  21 Project Data
  22 ------------
  23
  24 Data that describes a Linux Foundation Networking Project. Provide links to
  25 authoritative public content or steps to reproduce results when possible.
  26
  27 Project Vitals
  28 ==============
  29
  30 Basic information about the candidate project.
  31
  32 * Project name
  33 * Project creation date
  34 * Project license
  35 * Project release schedule
  36
  37   * History of at least two years or age of project
  38   * Planned future release schedule
  39
  40 * Statement of alignment with LFN Charter/Mission
  41
  42 Community Historical Trends
  43 ===========================
  44
  45 History of the candidate project's community.
  46
  47 For each release or year for at least the last two years or the lifespan of the
  48 project, provide the following.
  49
  50 * Contribution statistics
  51
  52   * Number of commits
  53   * Number of non-trivial (generated code, version bump, ...) commits >5k LoC
  54
  55     * Merged by uploader
  56     * Merged by committer from same organization as uploader
  57     * Merged without substantial code review
  58     * If the candidate project has sub-projects, group these by sub-project
  59
  60   * Number of commits per-organization
  61
  62 * Contributor statistics
  63
  64   * Number of contributors
  65   * Number of contributors per-organization
  66
  67 Community Current Status
  68 ========================
  69
  70 Snapshot of the candidate project's community.
  71
  72 * Committer statistics
  73
  74   * Number of committers
  75   * Number of committers per-organization
  76   * Number of active committers
  77   * Number of active committers per-organization
  78
  79 * Contributor approval process
  80
  81   * Contributor eligibility
  82   * Process to become a contributor
  83   * Process to remove a contributor
  84
  85 * Committer approval process
  86
  87   * Committer eligibility
  88   * Process to become a committer
  89   * Process to remove a committer
  90
  91 * Project governance structure
  92
  93   * Summery of project governance structure
  94   * Summery of how project governance was established and can be modified
  95   * Links to all public project governance documentation
  96   * List of all community roles and details of how they are filled/emptied
  97   * List of community roles that are elected
  98   * List of community roles that are appointed
  99   * List of people in all community roles and their organization affiliation
 100
 101 * User community
 102
 103   * Summary of project user community
 104
 105 Project Functionality
 106 =====================
 107
 108 Details about the functionality of the candidate project.
 109
 110 * Summary of candidate project functionality
 111 * Summary of candidate project technology components and purposes
 112 * Summary of where candidate project complements functionality already provided
 113   by project(s) within LFN
 114 * Summary of where candidate project overlaps functionality already provided by
 115   project(s) within LFN
 116
 117 Project Tooling
 118 ===============
 119
 120 Details about the tooling used by the candidate project.
 121
 122 * Bug tracker
 123
 124   * Links to bug trackers used by the candidate project.
 125   * Integrated with any other relevant projects?
 126   * To what extent are external/private bug trackers used?
 127
 128 * Chat tooling
 129
 130   * Links to chat tooling used by the project.
 131   * Overview of chat tooling used by the candidate project.
 132   * To what extent is external/private chat tooling used?
 133
 134 * Code repositories
 135
 136   * Links to code repositories used by the candidate project.
 137   * Overview of code repositories used by the candidate project.
 138   * To what extent are external/private code repositories used?
 139
 140 * Code review
 141
 142   * Links to code review systems used by the candidate project.
 143   * Overview of code review norms, practices, conventions, rules.
 144   * To what extent are external/private code review systems used?
 145
 146 * Continuous Integration tooling
 147
 148   * Links to CI jobs.
 149   * Links to CI job definitions, infrastructure configuration.
 150   * Overview of CI related to the candidate project.
 151   * To what extent are external/private CI systems used?
 152
 153 * Documentation
 154
 155   * Links to documentation for the candidate project.
 156
 157 * Mailing lists
 158
 159   * Links to mailing lists used by the project and their archives.
 160   * Overview of mailing lists used by the candidate project.
 161   * To what extent are external/private mailing lists used?
 162
 163 * Meeting calendars
 164
 165   * Link to docs about meetings related to the candidate project.
 166   * Overview of meetings held by the candidate project.
 167   * To what extent are meetings public, and clearly publicly documented?
 168
 169 * Meeting minutes
 170
 171   * Link to archives for meeting minutes taken by the candidate project.
 172   * To what extent are public minutes for meetings taken and shared?
 173
 174 Integrations
 175 ============
 176
 177 Details about technical integrations implemented by the candidate project.
 178
 179 * Summarize any existing or planned integrations with other projects.
 180 * Summarize any CI/CD integrations with other projects.
 181 * Summarize any other work that may enable integrations in the future.
 182
 183   * Continuous Delivery pipelines
 184   * Configuration management tooling
 185   * Documentation about cross-project integration
 186   * APIs for cross-project integration
 187
 188 Vocabulary Reference
 189 --------------------
 190
 191 Explanations of domain-specific vocabulary.
 192
 193 .. todo:: Look into using special rst to make these definitions into tooltips
 194 .. todo:: Consider extracting this to a stand-along file so can reuse elsewhere
 195
 196 * Active
 197
 198   * In this context, typically related to the activity level of a project or
 199     person.
 200   * As a person: "Foo Committer on Bar Project has not sent any patches or done
 201     any code review for Bar in the last 12 months. Bar's Project Lead reached
 202     out to Foo Committer to discuss transitioning to an Emeritus Committer."
 203   * As a project: "Bar Project has not had any non-trivial code changes merged
 204     in the last 12 months. The LFN TAC reached out to Bar Project to discuss
 205     transitioning to the LFN Archived lifecycle state."
 206   * The LFN norm for "active" is about 12 months.
 207
 208 * Committer
 209
 210   * Person with permission to cause commits to be merged into a project's
 211     source control repositories.
 212
 213 * Contributor
 214
 215   * Person who has contributed to a project. "Contributions" are broadly
 216     defined. Examples include things like code, documentation, and bug tracker
 217     changes.
 218
 219 * Diverse
 220
 221   * In this context, typically related to the number of different organizations
 222     involved in a project.
 223
 224 * Downstream
 225
 226   * In this context, typically means the products based on a project.
 227     Community collaborates on upstream project, which is downstreamed by a
 228     company into a product.
 229   * Alternatively, could relate to a relationship between two "upstream" open
 230     source projects (not by-company products) where one consumes (is downstream
 231     of) the other.
 232   * As a verb: "to copy something from the open source project to a product
 233     based on it".
 234   * As a dependency relationship: "Linux is a downstream of C".
 235
 236 * Upstream
 237
 238   * In this context, typically means the main open source project a community
 239     collaborates on. The code, tooling and people that comprise a project.
 240   * As a verb: "to add something to the main open source project".
 241   * As a dependency relationship: "C is an upstream of Linux".