Активність розробки

Активність розробки відповідає на перше питання, яке ставлять будь-якій залежності з відкритим кодом: чи пишеться код активно? Метрика читає історію push і комітів репозиторію за останній рік і винагороджує свіжість, ритм та обсяг — саме в такому порядку ваги.

• Категорія: Життєздатність (60% у межах категорії)
• Вага в загальному індексі: 12.6%
• Ключ метрики: development_activity

Як обчислюється значення

Значення — це зважена сума, округлена та обмежена діапазоном 1–100, яка відповідає одному з діапазонів рейтингу. Компоненти без даних виключаються, а ваги решти перенормовуються (див. індекс здоров'я).

Maintained — це спільне підтвердження, а не заміна власної історії комітів сканера: воно також залишається повноцінним компонентом стану безпеки. Якщо Scorecard недоступний або позначає перевірку як n/a, цей компонент виключається.

Коефіцієнт людського авторства

Ритм і обсяг рахують коміти, а коміт, зроблений роботом, рахується точно так само, як коміт, зроблений мейнтейнером. Тому репозиторій, чий бот залежностей щотижня відкриває та зливає оновлення, читається як такий, що перебуває під безперервною розробкою.

Найновіші 100 комітів перевіряються на те, хто є їхнім автором, і два компоненти, що рахують коміти, множаться на людську частку цього вікна, досягаючи повного бала за 40% і вище.

Мають виконуватися дві умови водночас. Сама лише низька людська частка означає тільки те, що проєкт активно автоматизує, — а найкраще підтримувані проєкти часто так і роблять: інструмент із 59 000 зірок проганяє приблизно три чверті своїх комітів через бот залежностей, а реєстр пакетів, чий продукт і є автоматизованим підвищенням версій, — ще більше. В обох людські коміти дводенної давнини. Тому дисконт додатково вимагає, щоб жодна людина не комітила понад 90 днів: проєкт позначає як підтримуваний роботами саме тиша, а не автоматизація.

Розрив вимірюється всередині самого вікна комітів — найновіший коміт проти найновішого людського, — тож збережений звіт завжди перераховується на те саме значення, а не дрейфує зі старінням.

Коефіцієнт не має власної адитивної ваги — він може лише знизити значення, ніколи не підвищити, — і повністю пропускається, коли вибірка комітів недоступна або менша за 20 комітів, тож із замалого обсягу свідчень нічого не виводиться. Розпізнається лише автоматика з ідентичністю GitHub App; бот, що працює під звичайним обліковим записом користувача, і далі рахується людиною.

Чому ритм важить більше за обсяг

Репозиторій із комітом щотижня протягом року — надійніший доказ супроводу, ніж та сама кількість комітів, залита одним сплеском. Ритм вимірює постійність уваги; обсяг масштабується логарифмічно саме для того, щоб кількість комітів не можна було роздути до високого значення — різниця між 100 і 1 000 комітів на рік невелика за задумом.

Як читати результат

• Свіжість домінує в короткостроковій зміні. Проєкт, що зупиняється на шість місяців, спершу втрачає компонент свіжості; далі згасає компонент ритму — в міру накопичення неактивних тижнів.
• По-справжньому завершене програмне забезпечення існує. Стабільна, функціонально повна бібліотека може читатися тут низько, залишаючись безпечною у використанні — саме тому активність розробки є однією метрикою всередині зваженого індексу, а не вироком. Перечитуйте разом із дисципліною релізів та оперативністю.
• Монорепозиторії та дзеркала: активність читається з репозиторію, що інспектується; робота в іншому репозиторії не зараховується.

Як покращити значення

• Зливати підтримувану роботу безперервно замість накопичення довгоживучих гілок.
• Підтримувати принаймні щотижневий пульс реальних змін там, де проєкт справді потребує супроводу — оновлення залежностей та виправлення помилок зараховуються.
• Уникати порожньої активності: логарифмічна шкала обсягу робить штучне роздування комітів майже нічого не вартим.

Дивіться також: дисципліна релізів · Життєздатність