Що робити із покинутими проблемами в GitHub?

Якщо хтось відкриває проблему на GitHub, але більше інформації про відтворення помилки запитується і ніколи не надається, яка нормальна процедура? Приклад .

Тут автор констатує, що «нави переривається». Хоча я вважаю, що це виправлено, я хотів би сказати слово автора, щоб переконатися, що ми говорили про те саме. Але іноді репортер випуску просто зникає. Чи є гарною / поширеною практикою встановлення терміну придатності для покинутих питань?

Приблизно такі умови:

• У питанні виникає питання, щоб мати змогу налагодити його.
• Минуло 2–6 місяців з часу останнього не відповіді на запитання / коментар від команди розробників.
• Помилка не може бути відтворена під час закриття (з будь-якої причини, можливо, їх ніколи не можна відтворити).
• Попередження видається за 2 тижні до його закриття.

Що зазвичай роблять проекти? Я нічого не зміг знайти в Google. Крім того, як я це документував? Чи достатньо простої примітки в README.md із деталізацією вищезазначених пунктів та коментарем у питанні, що пояснює, чому це закриття?

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

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

Таким чином, ви повинні закрити його, але , ймовірно , не як «фіксованою». Ви можете придумати власну близьку причину "можливофіксований" або "непідтверджений виправлення", якщо ви хочете бути позитивною або "репортованою", якщо цього не зробите. Ви також можете просто сказати, що "не вдалося відтворити", і чекати, коли той самий помилок з'явиться для більш чуйного репортера.

Однак вам не слід витрачати ресурси на помилку, за яку ви ніколи не дізнаєтесь, чи вона була фактично виправлена ​​чи ні.

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

Рішення, яке я бачив у багатьох проектах, полягає не в тому, щоб розмістити його у проекті README.md, а у спеціальному внеску README - файл README для учасників. Цей файл описує все, що ви хочете, щоб люди, які сприяли вашому проекту, знали - будь то про код (іменування конвенцій, організацію модулів тощо) або про процес (як писати комісії, як обробляти квитки тощо). Цей файл може бути іншим .MDфайлом у проекті або розміщеним у зовсім іншому сховищі (таким чином він може бути спільним для всіх ваших проектів). Тільки не забувайте посилатися на нього з головного README.md!

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

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

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

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

Переглядаючи стандартний робочий процес Bugzilla, ми отримуємо:

Я хочу зазначити дуже важливу річ, яку він вирішує як фіксований, перш ніж він закриється після перевірки . Основний робочий процес Github показує лише червоний (відкритий) та зелений (закритий) стани.

Таким чином, одним із підходів є використання міток Github ( міток вашої програми ), щоб спробувати показати додаткову інформацію. Ви можете створити пару міток, які "неперевірені" та "перевірені", які слід застосувати після закриття проблеми. Зауважте, що це лише один підхід - якщо здійснити пошук, ви можете знайти десятки різних підходів до використання міток. Тут питання, як керувати проблемами github для (пріоритет тощо)? вирішує це.

Ви виправили це, з точки зору розробника, це робиться. Закрийте випуск на Github. Нанесіть на нього "неперевірену" мітку. Після того, як хтось, знайомий з помилкою в попередній версії, сказав "так, це виправлено", ви можете змінити мітку на "перевірено". Якщо вони кажуть, що цього не сталося, тоді ви знову відкриєте це.

Зауважте також, що існують й інші вирішені стани, окрім "виправлених". Існує 'wontfix' (виправлення - це те, що просто неможливо зробити із поточною структурою) та 'worksforme' (помилка не може бути відтворена) та 'invalid' (ви подаєте помилку про ОС, а не речі типу додатка).

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

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

2) Оскільки репортера більше немає, вважайте, що помилка не може бути (як відомо) відтворена, оскільки лише слово репортера для неї підтверджує, що це те саме, що вони повідомляли. Підніміть нову помилку, щоб описати виправлену річ, задля того, щоб згадати, що вона спостерігалась за умов, описаних відсутнім репортером, зауважте, що вони можуть бути дублікатами, позначте нову помилку виправленою та позначте цю недійсну чи не відтворюється з приміткою на кшталт: "Я не можу розібратися, що ви мали на увазі під" перервами ", але я вирішив проблему, яку я знайшов. Будь ласка, знову відкрийте або підніміть нову помилку, якщо навик все-таки зламається, описуючи в докладніше, що піде не так ".

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

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