Чи слід писати повідомлення про вчинення у поточному чи минулому часі? [зачинено]

Отже, що це, на вашу думку, краще та інтуїтивніше?

Fixed the XXX bug in YYY
Fix the XXX bug in YYY
Fixes the XXX bug in YYY
Fixing the XXX bug in YYY

Будь ласка, надайте свої обгрунтування. Примітка. Я прошу з вашої загальної точки зору, це означає, що ви не повинні намагатися пов'язувати це з улюбленими інструментами svn / cvs або мовами програмування, а вважати це як щось, що повинно / може бути застосоване до будь-яких інструментів та мов програмування.

Я думаю про ці повідомлення, як вони з’являються перед іншими розробниками. Вони ще не застосовують зміни, і виникає неявний питання, "що буде застосовувати цей набір змін / виправлення?" Це "Виправить XXX помилку у РРРР"!

Для інших дієслів написання їх як команди здається більш природним, і працює краще, якщо у вас є конкретна мета вперед - ви можете буквально написати конспект виконання разом з попередніми тестами до того, як буде виконана робота.

Я не ставлю на це велику вагу, але для мене це шлях найменшого опору при збереженні послідовності.

Я особисто йду з минулим часом ("виправлено"), оскільки до моменту, коли я прихожу до вчинення помилки, виправлено (або я б не робив цього).

Я вважаю за краще бачити повідомлення про вчинення в поточному часі. Таким чином у повідомленні описується те, що робить різниця (тому що ви можете перетягнути цю різницю або навіть зробити цілу команду в іншу гілку). Таким чином, повідомлення про фіксацію не описує те, що воно "робило" ... Він описує те, що робить "виконувати" сам. Тож має бути в теперішньому часі.

Уявіть, що дивитесь на різницю в ізоляції та намагаєтесь вирішити, чи застосовуватимете ви її. Немає сенсу мати титул у минулому часі.

IMHO, якщо ви хочете, щоб він був описовим без необхідності враховувати контекст, тоді "Виправлений", безумовно, єдиний правильний варіант.

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

"Виправлення" - це найгірший вибір ІМХО, оскільки його можна інтерпретувати не лише як опис того, що робиться (і) для виправлення, але і як статус помилки, що означатиме, що над ним працює і ще не вирішено.

Fix the XXX bug in YYY
Teach the XXX to be more ZZZ
Correct typos in javadoc

Взагалі: {imperative verb} {object object} {необов'язкові класифікатори}

Імперативна форма підходить для всіх випадків використання, коли я розглядаю патчсет.

• Що ти тут будеш робити?
• Що робить цей патчсет?
• Чому був створений цей патчсет? (виправити помилку xxx ...)
• Мені потрібно виправити помилку xxx у yyy. Чи є комісія в іншій галузі, яка вже робить це?

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

Я вважаю, що писати про поточний вчинок у нинішньому часі - це гарна ідея, оскільки це робить більш зрозумілим, коли ви посилаєтесь на попередні зобов’язання у минулому часі.

Я не думаю, що це насправді має значення. Мета:

1) Перекажіть, що робиться чи робиться, щоб помилки можна було легше знайти, проблеми можна повернути легше, і взагалі легше підтримувати проект.

2) Перекажіть, які квитки були зафіксовані, якщо такі є, то аудитори (якщо вони використовуються у вашій компанії, можуть побачити, які зміни відповідають, які квитки).

Нарешті, якщо це "вже виправлено", "Виправлення" не має сенсу, і якщо ви все ще працюєте над ним, "Виправлено" не вірно.

" Виправити помилку X " на 2 символи коротше, ніж " Виправлена ​​помилка X ".
І на 3 коротше, ніж " Виправлення помилки X ".

З точки зору написання коротких повідомлень-повідомлень, теперішній час іноді / зазвичай економить кілька символів?
Я думаю, що насправді має значення небагато, наприклад, з рекомендацією Гіта про менше, ніж 50 символів, на першу позицію повідомлення.
Крім того, менше тексту -> швидше читання?

Повідомлення комісії описує, чому ви написали код, який виконується.

"Виправлена ​​помилка 3124" або "Виправлення випуску 3124" здається правильною, оскільки вона говорить, що цей код виправлений | виправляє виправлення 3124.

Однак граматика також може залежати від того, чому маркує помилку як виправлену. Якщо ви можете позначати помилку як виправлену після скоєння, то "Виправлена" - це просто добре, але якщо помилку буде позначено як виправлену кимось іншим після того, як вони перевірять ваш код, то "Виправлення" може бути більш підходящим.

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

Хоча я бачу переваги використання теперішнього часу (і насправді натрапив на цю посаду, тому що я бачив кілька справжніх повідомлень про напругу в проектах з відкритим кодом), я, мабуть, ніколи не буду використовувати сучасний час для моїх проектів. Це рекомендований спосіб для Linux та Git, і, ймовірно, інших великих проектів з відкритим кодом, але я, чесно кажучи, не хвилююся, доки я не є частиною цих проектів.

Я інді-розробник і використовую перший рядок повідомлення про фіксацію приміток до випуску, тоді як опис у наступних рядках дає мені уявлення про деталі реалізації. Це орієнтований на користувачів робочий процес у порівнянні з сучасним підходом для розробників. Я можу заощадити деякий час таким чином. Було б вкрай неприродно давати моїм користувачам інструкції у примітках до випуску. Моя робота - виправляти помилки та додавати функції. Мені потрібно економити час, бо я інді. У мене в колективі не існує «письменника-випусника».

Використовуйте правила проекту, якщо вони вже створені, але будьте прагматичними та робіть все, що полегшить чи швидше зробить вашу роботу.

Я думаю, що "Fixes XXX bug"має більше сенсу, ніж "Fix XXX bug"якщо причина використання теперішнього часу полягає в тому, щоб "зробити його більш описовим для того, що робить", а не того, що робив комітер.

Якщо це невелика фіксація, я використовую поточний безперервний:

Виправлення помилки 304

або

Додавання коментарів

Якщо це велика комісія, я роблю більше журналу змін:

• Виправляє помилки 453, 657 та 324
• Додавання синтаксису виразів
• Відновлено клас оператора.