coreinfrastructure · david-a-wheeler · Apr 8, 2021 · Mar 30, 2021 · Apr 1, 2021
diff --git a/config/locales/en.yml b/config/locales/en.yml
@@ -1242,6 +1242,36 @@ en:
           and reviewers worldwide. A project can meet this criterion
           even if its core developers' primary language is not
           English.
+      maintained:
+        description: >-
+          The project MUST be maintained.
+        details: >-
+          As a minimum, the project should attempt to respond to
+          significant problem and vulnerability reports.
+          A project that is actively pursuing a badge is probably maintained.
+          All projects and people have limited resources, and typical projects
+          must reject some proposed changes, so limited resources and proposal
+          rejections do not by themselves indicate an unmaintained project.
+          <br><br>
+          When a project knows that it will no longer be maintained,
+          it should set this criterion to "Unmet" and use the
+          appropriate mechanism(s) to indicate to others that
+          it is not being maintained.
+          For example, use “DEPRECATED” as the first heading of its README,
+          add “DEPRECATED” near the beginning of its home page,
+          add “DEPRECATED” to the beginning of its code repository
+          project description,
+          add a <a href="https://unmaintained.tech/">no-maintenance-intended
+          badge</a> in its README and/or home page,
+          mark it as deprecated in any package repositories (e.g.,
+          <a href="https://docs.npmjs.com/deprecating-and-undeprecating-packages-or-package-versions”>npm deprecate</a>),
+          and/or use the code repository's marking system to archive it (e.g.,
+          GitHub's <a href="https://docs.github.com/en/[email protected]/github/creating-cloning-and-archiving-repositories/archiving-a-github-repository">"archive" setting</a>,
+          GitLab’s <a href="https://docs.gitlab.com/ee/user/project/settings/#archiving-a-project">"archived" marking</a>,
+          Gerrit's "readonly" status, or
+          SourceForge’s "abandoned" project status).
+          Additional discussion can be found
+          <a href="https://medium.com/maintainer-io/how-to-deprecate-a-repository-on-github-8f0ceb9155e">here</a>.
       repo_public:
         description: >-
           The project MUST have a version-controlled source repository

diff --git a/criteria/criteria.yml b/criteria/criteria.yml
@@ -184,6 +184,29 @@
             We can use more general tools to detect the natural language,
             or simple mechanisms like using dictionaries/spellcheckers to
             see if it's mostly English.
+      - maintained:
+          category: MUST
+          autofill: >
+            Look at the repo page.
+            To detect projects that have expressly stated that they are
+            not maintained,
+            look for “DEPRECATED” as the first heading of its README title,
+            “DEPRECATED” to the beginning of its GitHub project description
+            (if it is on GitHub), a
+            <a href="https://unmaintained.tech/“>no-maintenance-intended badge</a>
+            in its README, and/or
+            the code repository's marking system (e.g.,
+            GitHub’s <a href="https://docs.github.com/en/[email protected]/github/creating-cloning-and-archiving-repositories/archiving-a-github-repository">”archive” setting</a>,
+            GitLab’s <a href="https://docs.gitlab.com/ee/user/project/settings/#archiving-a-project”>“archived” marking</a>,
+            Gerrit’s “readonly” status, or
+            SourceForge’s “abandoned” project status).
+            Additional discussion can be found <a href="https://medium.com/maintainer-io/how-to-deprecate-a-repository-on-github-8f0ceb9155e">here</a>.
+            To detect projects that have simply stopped being maintained,
+            look for projects more than X lines of code (or size) that
+            have had no response activity in more than Y months (in either the
+            project or badge). Creating issues & pull requests do not count
+            as responses (since they may be from those outside the project);
+            commits and releases *do* count as response activity.
   - 'Change Control': !!omap
     - Public version-controlled source repository: !!omap
       - repo_public:

diff --git a/db/migrate/20210330015708_add_maintained_criterion.rb b/db/migrate/20210330015708_add_maintained_criterion.rb
@@ -0,0 +1,21 @@
+# frozen_string_literal: true
+
+# Copyright CII Best Practices badge contributors
+# SPDX-License-Identifier: MIT
+
+class AddMaintainedCriterion < ActiveRecord::Migration[6.1]
+  def change
+    # This "status" has the *very* unusual default value 'Met'.
+    # We assume that, barring any other information, a project that is
+    # working to earn a badge is being maintained (since it is actively
+    # thinking about improvement), and thus it is Met by default.
+    add_column :projects, :maintained_status, :string,
+               null: false, default: 'Met'
+    add_column :projects, :maintained_justification, :text
+
+    # We have a different number of passing criteria, so we need to
+    # recalculate all project percentages at that level.
+    # This takes about 1 minute 36 seconds on my development machine.
+    Project.update_all_badge_percentages(['0'])
+  end
+end
diff --git a/db/schema.rb b/db/schema.rb
@@ -10,7 +10,7 @@
 #
 # It's strongly recommended that you check this file into your version control system.
 
-ActiveRecord::Schema.define(version: 2021_02_16_184638) do
+ActiveRecord::Schema.define(version: 2021_03_30_015708) do
 
   # These are extensions that must be enabled in order to support this database
   enable_extension "citext"
@@ -375,6 +375,8 @@
     t.datetime "first_achieved_passing_at"
     t.datetime "first_achieved_silver_at"
     t.datetime "first_achieved_gold_at"
+    t.string "maintained_status", default: "Met", null: false
+    t.text "maintained_justification"
     t.index ["achieved_gold_at"], name: "index_projects_on_achieved_gold_at"
     t.index ["achieved_passing_at"], name: "index_projects_on_achieved_passing_at"
     t.index ["achieved_silver_at"], name: "index_projects_on_achieved_silver_at"

diff --git a/doc/criteria.md b/doc/criteria.md
@@ -251,6 +251,8 @@ There is an implied criterion that we should mention here:
 <li><a name="discussion"></a>The project MUST have one or more mechanisms for discussion (including proposed changes and issues) that are searchable, allow messages and topics to be addressed by URL, enable new people to participate in some of the discussions, and do not require client-side installation of proprietary software. <sup>[<a href="#discussion">discussion</a>]</sup><dl><dt><i>Details</i>:<dt> <dd>Examples of acceptable mechanisms include archived mailing list(s), GitHub issue and pull request discussions, Bugzilla, Mantis, and Trac. Asynchronous discussion mechanisms (like IRC) are acceptable if they meet these criteria; make sure there is a URL-addressable archiving mechanism. Proprietary JavaScript, while discouraged, is permitted.</dd></dl></li>
 
 <li><a name="english"></a>The project SHOULD provide documentation in English and be able to accept bug reports and comments about code in English. <sup>[<a href="#english">english</a>]</sup><dl><dt><i>Details</i>:<dt> <dd>English is currently the <a href="https://en.wikipedia.org/wiki/Lingua_franca">lingua franca</a> of computer technology; supporting English increases the number of different potential developers and reviewers worldwide. A project can meet this criterion even if its core developers' primary language is not English.</dd></dl></li>
+
+<li><a name="maintained"></a>The project MUST be maintained. <sup>[<a href="#maintained">maintained</a>]</sup><dl><dt><i>Details</i>:<dt> <dd>As a minimum, the project should attempt to respond to significant problem and vulnerability reports. A project that is actively pursuing a badge is probably maintained. All projects and people have limited resources, and typical projects must reject some proposed changes, so limited resources and proposal rejections do not by themselves indicate an unmaintained project. <br><br> When a project knows that it will no longer be maintained, it should set this criterion to "Unmet" and use the appropriate mechanism(s) for their repositories to indicate that it is not being maintained. For example, use “DEPRECATED” as the first heading of its README title, add “DEPRECATED” to the beginning of its GitHub project description if it is on GitHub, add a <a href="https://unmaintained.tech/">no-maintenance-intended badge</a> in its README, and/or use the code repository's marking system (e.g., GitHub's <a href="https://docs.github.com/en/[email protected]/github/creating-cloning-and-archiving-repositories/archiving-a-github-repository">"archive" setting</a>, GitLab’s <a href="https://docs.gitlab.com/ee/user/project/settings/#archiving-a-project">"archived" marking</a>, Gerrit's "readonly" status, or SourceForge’s "abandoned" project status). Additional discussion can be found <a href="https://medium.com/maintainer-io/how-to-deprecate-a-repository-on-github-8f0ceb9155e">here</a>.</dd></dl></li>
 </ul>
 
 ### Change Control

diff --git a/test/models/project_test.rb b/test/models/project_test.rb
@@ -216,8 +216,8 @@ class ProjectTest < ActiveSupport::TestCase
 
   test 'test get_satisfaction_data' do
     basics = @unjustified_project.get_satisfaction_data('0', 'basics')
-    assert_equal '9/12', basics[:text]
-    assert_equal 'hsl(90, 100%, 50%)', basics[:color]
+    assert_equal '10/13', basics[:text]
+    assert_equal 'hsl(92, 100%, 50%)', basics[:color]
     reporting = @unjustified_project.get_satisfaction_data('0', 'reporting')
     assert_equal '5/8', reporting[:text]
     assert_equal 'hsl(75, 100%, 50%)', reporting[:color]