IP
вроде ж это чистый теорвер
Size: a a a
2021 January 02
AN
вроде ж это чистый теорвер
А что такое чистый теорвер? Принятие решений - это тоже моя первая лекция по статам. А по сушеству, в средних значениях, это разумеется давно разобрали. Там только есть нюансы с распределениями с длинными хвостами (ишью по 6 лет) и сцепленными задачами, которые на аналитике не учтешь.
I
Ну что-нибудь похожее, так точно. Оно все стоится на теории принятия решений, разумеется.
Ну я ссылался на закон Литтла, если есть такая метрика и среднее количество открытых багов, то известен средний поток багов (он непостоянен из-за релизов и еапов), из которого становится примерно понятно, насколько большое ядро early adopters и сколько ждать со стабилизацией фич, чтобы подавляющее большинство багов было найдено и закрыто.
AN
AN
Ну я ссылался на закон Литтла, если есть такая метрика и среднее количество открытых багов, то известен средний поток багов (он непостоянен из-за релизов и еапов), из которого становится примерно понятно, насколько большое ядро early adopters и сколько ждать со стабилизацией фич, чтобы подавляющее большинство багов было найдено и закрыто.
Это понятно. Но это сильно усредненная штука.
BP
так это не его калитка
IP
А что такое чистый теорвер? Принятие решений - это тоже моя первая лекция по статам. А по сушеству, в средних значениях, это разумеется давно разобрали. Там только есть нюансы с распределениями с длинными хвостами (ишью по 6 лет) и сцепленными задачами, которые на аналитике не учтешь.
на каждый шестилетний issue найдется балбес, который его отроет, пока он не станет семилетним
I
Это понятно. Но это сильно усредненная штука.
И?
AN
на каждый шестилетний issue найдется балбес, который его отроет, пока он не станет семилетним
При стремлении размера системы к бесконечной - да. А на конечной нет.
BP
ага)
AN
И?
Можно сторить неравновесную модель динамики с учетом ваших собственных распределений. Например можно понять, надо ли вообще фиксить баги 6-летней давности
IP
При стремлении размера системы к бесконечной - да. А на конечной нет.
для каждой n-летней баги найдется балбес, пока она не станет (n+1)-летней
IP
индукция же ж
AN
И?
Вот кстати этот самый закон для треккера бесполезен практически, потому что распределение багов по времени обработки очень кривое. Оно и многомодное при этом. И то, что багу сложно чинить не значит, что ее решение кому-то нужно.
I
Можно сторить неравновесную модель динамики с учетом ваших собственных распределений. Например можно понять, надо ли вообще фиксить баги 6-летней давности
Я что-то не понимаю. Это же хвост, причём настолько дальний, что поток событий уже не поток, а одиночные события и каждое такое событие - огромный всплеск.
AN
Там еще есть очень хитрый фактор, что есть оценочная сложность и есть реальная. Они не совпадают в общем случае и надо брать несколько разных моделей оценивания сложности. Также есть видимая важность (чувак пишет, что он умирает без этой фичи), а есть реальные средние потери по ансамблю. Это отличие тоже надо учитывать
AN
Я что-то не понимаю. Это же хвост, причём настолько дальний, что поток событий уже не поток, а одиночные события и каждое такое событие - огромный всплеск.
А вот тут вопрос в том, как у тебя потери накапливаются. Надо ли умножать время решения бага на его критичность или брать только количество нерешенных багов. Я это в лекции кратенько разбирал
IP
Там еще есть очень хитрый фактор, что есть оценочная сложность и есть реальная. Они не совпадают в общем случае и надо брать несколько разных моделей оценивания сложности. Также есть видимая важность (чувак пишет, что он умирает без этой фичи), а есть реальные средние потери по ансамблю. Это отличие тоже надо учитывать
а чувака, который умирает, жалко
I
Вот кстати этот самый закон для треккера бесполезен практически, потому что распределение багов по времени обработки очень кривое. Оно и многомодное при этом. И то, что багу сложно чинить не значит, что ее решение кому-то нужно.
Так их того же трекера можно понять, какой функцией её аппроксимировать. Что даёт уточнение модели.