GitHub issues как один из источников входящих
Добавлено: Сб мар 10, 2018 11:38 am
Привет!
Относительно недавно за особые заслуги на ниве программирования меня сделали ведущим одного open source проекта. Так что теперь, помимо всего прочего, GitHub issues стали ещё одним источником моих входящих.
Для тех, кто не в курсе, GitHub это такая система (преимущественно для программистов, но представители других профессий тоже используют), в которой можно хранить проекты, исходные коды (с версионированием), wiki, задачи (issues) и "проекты" (группировка issues в некое подобие kanban-доски).
По началу, пункт "опустошить входящие" из периодических обзоров вызывал ступор – как можно "опустошить" issues, если единственный способ их как-то "скрыть" из этого инбокса, это закрыть их с какой-то резолюцией (выполнено, дубликат, не проблема, и т д)? Но сейчас в процессе написания в голове возникает решение: надо просто все issues, у которых не назначен исполнитель, считать инбоксом.
Подобный приём, когда в процессе описания проблемы, находится её решение, я подсмотрел в книге Брайана Кернигана и Роберта Пайка "Практика программирования". Там этот приём назывался "поговорить с медведем", авторы советовали рассказывать о каком-то проблеме плюшевому медведю (в те времена ещё не было форумов и всего этого интернета).
Так что можно записать себе в ВИП-лист новую практику: "говорил с медведем".
Спасибо за внимание!
P.S. Прошу прощения за несколько скомканное повествование. Писал с телефона и урывками.
Относительно недавно за особые заслуги на ниве программирования меня сделали ведущим одного open source проекта. Так что теперь, помимо всего прочего, GitHub issues стали ещё одним источником моих входящих.
Для тех, кто не в курсе, GitHub это такая система (преимущественно для программистов, но представители других профессий тоже используют), в которой можно хранить проекты, исходные коды (с версионированием), wiki, задачи (issues) и "проекты" (группировка issues в некое подобие kanban-доски).
По началу, пункт "опустошить входящие" из периодических обзоров вызывал ступор – как можно "опустошить" issues, если единственный способ их как-то "скрыть" из этого инбокса, это закрыть их с какой-то резолюцией (выполнено, дубликат, не проблема, и т д)? Но сейчас в процессе написания в голове возникает решение: надо просто все issues, у которых не назначен исполнитель, считать инбоксом.
Подобный приём, когда в процессе описания проблемы, находится её решение, я подсмотрел в книге Брайана Кернигана и Роберта Пайка "Практика программирования". Там этот приём назывался "поговорить с медведем", авторы советовали рассказывать о каком-то проблеме плюшевому медведю (в те времена ещё не было форумов и всего этого интернета).
Так что можно записать себе в ВИП-лист новую практику: "говорил с медведем".
Спасибо за внимание!
P.S. Прошу прощения за несколько скомканное повествование. Писал с телефона и урывками.