<commit_before># Best Practices Criteria for Free/Libre and Open Source Software (FLOSS)

<!-- SPDX-License-Identifier: (MIT OR CC-BY-3.0+) -->
<!-- DO NOT EDIT generated file criteria.md !! -->
<!-- The actual criteria are stored in criteria/criteria.yml . -->
<!-- See also files criteria-header.markdown and criteria-footer.markdown . -->

## Introduction

This is a set of best practices
for Free/Libre and Open Source Software (FLOSS) projects.
Projects that follow these best practices
will be able to voluntarily self-certify and show that they've
achieved a Core Infrastructure Initiative (CII) badge.
Projects can do this, at no cost,
by using a web application (BadgeApp)
to explain how they meet these practices and their detailed criteria.

There is no set of practices that can guarantee that software
will never have defects or vulnerabilities;
even formal methods can fail if the specifications or assumptions are wrong.
Nor is there any set of practices that can guarantee that a project will
sustain a healthy and well-functioning development community.
However, following best practices can help improve the results
of projects.
For example, some practices enable multi-person review before release,
which can both help find otherwise hard-to-find technical vulnerabilities
and help build trust and a desire for repeated interaction among developers
from different organizations.

These best practices have been created to:

1. encourage projects to follow best practices,
2. help new projects discover what those practices are, and
3. help users know which projects are following best practices
   (so users can prefer such projects).

We are currently focused on identifying best practices
that well-run projects typically already follow.
The best practices, and the more detailed criteria
specifically defining them, are inspired by a variety of sources.
See the separate "[background](./background.md)" page for more information.

See the
[draft criteria for higher/more advanced badges](./other.md) if you
are interested in possible future criteria.<commit_msg>Criteria-header: Note dictionary definition of "best practices"<commit_after># Best Practices Criteria for Free/Libre and Open Source Software (FLOSS)

<!-- SPDX-License-Identifier: (MIT OR CC-BY-3.0+) -->
<!-- DO NOT EDIT generated file criteria.md !! -->
<!-- The actual criteria are stored in criteria/criteria.yml . -->
<!-- See also files criteria-header.markdown and criteria-footer.markdown . -->

## Introduction

This is a set of best practices
for Free/Libre and Open Source Software (FLOSS) projects.
Projects that follow these best practices
will be able to voluntarily self-certify and show that they've
achieved a Core Infrastructure Initiative (CII) badge.
Projects can do this, at no cost,
by using a web application (BadgeApp)
to explain how they meet these practices and their detailed criteria.

There is no set of practices that can guarantee that software
will never have defects or vulnerabilities;
even formal methods can fail if the specifications or assumptions are wrong.
Nor is there any set of practices that can guarantee that a project will
sustain a healthy and well-functioning development community.
However, following best practices can help improve the results
of projects.
For example, some practices enable multi-person review before release,
which can both help find otherwise hard-to-find technical vulnerabilities
and help build trust and a desire for repeated interaction among developers
from different organizations.

These best practices have been created to:

1. encourage projects to follow best practices,
2. help new projects discover what those practices are, and
3. help users know which projects are following best practices
   (so users can prefer such projects).

The idiom "best practices" means
"a procedure or set of procedures that is preferred or considered
standard within an organization, industry, etc."
(source:
<a href="http://www.dictionary.com/browse/best-practice">Dictionary.com</a>).
These criteria are what we believe are
widely "preferred or considered standard"
in the wider FLOSS community.

The "passing" criteria listed here focus on identifying best practices
that well-run FLOSS projects typically already follow.
The criteria are inspired by a variety of sources;
see the separate "[background](./background.md)" page for more information.
See the
[criteria for higher/more advanced badges](./other.md) if you
are interested in the criteria for higher-level badges.
{'fraction_non_alphanumeric': 0.059213433495360145, 'fraction_numerical': 0.002209456473707468, 'mean_word_length': 4.694339622641509, 'pattern_counts': {'":': 0, '<': 13, '<?xml version=': 0, '>': 13, 'https://': 0, 'lorem ipsum': 0, 'www.': 1, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6173195', 'n_tokens_mistral': 1067, 'n_tokens_neox': 1030, 'n_words': 616}