После публикации проекта по адресу [email protected] привлек мое внимание, что у тех, кто в сообществе Foss, могут возникнуть опасения по поводу использования проприетарной системы DevLeopment, такой как GitHub.
Я оставлю это как для устаревших целей в качестве архива наших первых недели.
Будущие обновления будут в новом проекте Home на Gitlab и новый проект Wiki на Gitlab.
Я благодарю вас всех за ваш интерес к этому проекту и приветствую вас, чтобы следовать за нами на Gitlab. Я буду работать над обновлением нашего бота IRC в канале разработки, чтобы поддержать уведомления WebHook о новой системе. Я не буду обновлять эту страницу проекта дальше.
Проект с амбициозной целью синергетической интеграции всех ресурсов поддержки Debian и предложить простой и интуитивно понятный интерфейс с хорошо проверенными диагностическими процедурами.
Это ни в коем случае не предназначено для замены, и на самом деле во многом зависит от всех наших существующих ресурсов. Обоснование здесь заключается в том, что наша система растет в геометрической прогрессии, и мы - «Универсальная ОС», и что у нас есть ограниченные ресурсы поддержки, и не все знают, как и в каком порядке их можно правильно использовать, что приводит к многим известным и легко наблюдаемым вопросам.
Команда поддержки с выгоранием путем повторного обращения, известных проблем, которые мы уже решили, необходимость объяснить наши процедуры и политики, а также собирать (иногда) информацию, имеющую отношение к рассматриваемой проблеме и т. Д.
Отчуждение пользователя через отсутствие понимания систем и непродуктивное взаимодействие с сторонниками и тому подобное. Это было хорошо задокументированное мышление среди некоторых из наших лучших сторонников, я включил в себя, что мы не хотим, чтобы такие пользователи неопытны, потому что они просто станут привлекательностью на наши ресурсы, не способствуя нашему проекту. Также легко наблюдаемый факт, что разработчики и более опытные пользователи часто являются последними людьми, которые находят ошибки и проблемы, потому что они не только склонны быть менее авантюрными в пробовании другого программного обеспечения, потому что они уже знают, что им нравится и использует, и используют его так, как это было предназначено для использования. Требуется кто -то неопытным, чтобы попробовать всевозможные варианты и использовать вещи способами, которые обнаружат неясные ошибки. Это ценный товар, чтобы массы неопытных пользователей, которые будут исчезнуть на нашей постоянно растущей программной базе, раскрывая проблемы, которые мы бы не стали упустить. Однако мы должны убедиться, что обратная связь, которую мы получаем от этого ценного ресурса, имели значение и заводится в нужном месте без возникновения вышеупомянутой проблемы, поэтому нам нужен своего рода фильтр, который удовлетворяет их потребности, а также наши.
Мы также должны убедиться, что все усилия к этим двум вопросам используются. То есть мы не можем продолжать, чтобы пользователи приходили к нам с самообеспечением для решения проблемы, и эти усилия были недостаточно используются, потому что это не было должным образом задокументировано. Некоторые пользователи возвращаются и делятся решениями проблем, иногда мы создаем факт об этом, иногда в конечном итоге оказывается страница вики, отчет об ошибках и т. Д., Но большую часть времени это не так. Кроме того, мы не всегда знаем, что это было сделано, когда проблема возникла снова. Наша нынешняя система опирается на то, что наши сторонники помнят эти вещи, и когда те люди, которые помнят, не смотрят в то время, мы можем вернуться к выпуску № 2 и отчуждения наших пользователей, или не зарегистрированные или вообще не решаемые, даже неэффективно.
Клиент/фронт (чтения, проклятия, GTK, QT), диагностика (подписанные файлы диагностических деревьев), BOT (IRC), сервер (трекер выпуска)
Клиент будет мастером в стиле отчетов, который позволит пользователю выбирать программу (на более низких уровнях квалификации, используйте общие имена, такие как «FileManager», и создавать его автоматически обнаружить фактическое имя программы или использовать фонд Grab, где пользователь может нажать на окно и получить команду) и ввести описание их проблемы и должен иметь различные классы проблем (сеть, звуки, сбои, ошибки, сборки пакетов. С идентификатором проблемы и электронной почтой отскочил обратно к пользователю для конфиденциальности, с возможностью для пользователя отказаться от дальнейшего CC, отправив электронное письмо с трекером с идентификатором, сообщив ему, чтобы он остановился).
Затем первый уровень будет использовать диагностику для выполнения простых тестов и запрашивать дополнительные вопросы, а также собирать информацию и собирать отчет/журнал по этому вопросу.
Журналы, скорее всего, должны быть проанализированы/сериализованы/стерилизованы, чтобы удалить или заменить личные данные, такие как IPS, MAC, имена пользователей, возможно, даже имена пути/файлов, и заменить их общими, такими как 1.2.3.4 или 12: 34: 56: 78: 90 или тому подобное.
Затем, если проблема не может быть решена с помощью автоматических процессов диагностики, которые идентифицируют проблему, основанную на хорошо известных, изношенных и проверенных в борьбе с простыми решениями, клиент во втором уровне будет делать это точно так же, как и отчеты отчетов, и отчеты об ошибках (и/или посты на форуме/вики) и отображать их пользователю из существующих батов знаний, которые у нас уже есть.
Если проблема остается нерешенной, то, то это будет тогда в 3 -м уровне, способствуя пересылке проблемы с трекером выпуска и предоставил ему идентификационный номер, а затем отправит ее в наши инструменты поддержки (IRC/почтовые списки), которые у нас уже есть, из самого клиента, и если IRC используется, это будет облегчить боти. Не получает решения и не решает уйти, проблема может оставаться открытой и/или быть перенаправленной в списки рассылки, и они могут следить за тем, чтобы посетить веб -сайт Tracker с их идентификационным номером или повторно уведомлений по электронной почте по этому вопросу из трекера.
Если проблема до сих пор не решень, она может быть направлена на 4 -й уровень, что будет таким, как BTS (подача отчета на BTS, так как он определяется как программная проблема со стороны сторонников) или, возможно, вверх по течению.
Файлы дерева диагностики могут быть каким -то XML или тому подобным, и им необходимо подписано и проверено, основное диагностическое дерево будет очень похоже на то, что делает ReportBug, оно просто собирает некоторую предварительную информацию о системе и убедится, что его Debian, какая версия, арка и той источники, способные, и т. Д. Такие вещи, как выполнение звукового тестирования и спросите пользователя, услышали ли они звук, проверьте их миксер, попросите их проверить свои соединения и т. Д.
Эти файлы диагностических деревьев также будут способствовать получению дополнительной информации, используя команды, которые собирают больше информации, специфичной для типа рассматриваемой проблемы. Эти команды должны быть показаны и объяснены и проверены и проверены пользователем, а также отображаются отчеты/журналы/вывод и (необязательно) анализируют/сериализованы/стерилизованы для удаления любой личной информации. Эти диагностики должны быть подписаны и оценены, и трекер проблемы будет способствовать тому же, как и в отношении каких -либо хороших рейтинговых систем, используя только подписи GPG, а оценка решения не только приведет к тому, что клиент означает, что диагностика повышает его доверие, но и повышение доверия сторонников, которые способствуют этим участкам диагностики.
Когда это возможно, все механизмы безопасности, доступные от таких вещей, как Chroots, и механизмы безопасности на основе ядра, должны быть использованы для блокировки вещей, которые делают диагностику, и они должны быть простыми и неинтруительными. Мы не хотим создавать разумный инструмент для диагностики, всего лишь несколько простых проверок для известных проблем конфигурации, простых тестов и составления данных для дальнейшей поддержки.
Бот IRC должен быть не только контактом/прокси для пользователя для каналов поддержки IRC (вверх по большим дебатам), возможно, высказывается от имени пользователя в канале сгенерированным идентификатором пользователя или номером выпуска, что позволит нам обеспечить только пользователь только что -то, что касается вопросов, но и в том, что трекерс выпуска знает, какие ответы поддержки принадлежат к вопросу для последующих документов. такой. Это можно сделать различными способами, и могут быть записаны сценарии IRC клиента, или клиентские функции, используемые для выполнения этих идентификаторов, как обычный ник, или, возможно, сторонник может сообщить боту, чтобы «подписать» в проблему, чтобы разговор с ботом отправил информацию обратно пользователю, на которого вы подписаны.
Бот также облегчит доступ к собранному отчету с информацией, собранной диагностикой и представленной пользователем, разведя все болтовни о запуске очень распространенных команд и использования пастебинов и тому подобного. Кроме того, бот может вести себя как клиентский интерфейс для открытия новой проблемы в трекере (возможно, даже если он считается необходимым, только известным и зарегистрированным сторонником) кем -то в обычном автономном клиенте IRC.
Короче говоря, бот - это клей, который связывается с каналами поддержки IRC, и следует следить, чтобы убедиться, что информация заканчивается в правильном канале в зависимости от предпочтительного языка пользователя, филиала Debian, и, возможно, даже то, что у них есть упаковка или выпуск дистанции, поскольку у нас есть конкретные каналы для разных вещей (таким образом, устранение необходимости в других каналах к другим каналам и размышлениям о том, что они могут иметь к такому.
Трекер будет содержать метаданные по этой проблеме, он будет генерировать идентификатор проблемы, отслеживать любой адрес CC, который поставлял пользователь, и где отчеты находятся (Sast.debian.net, скорее всего,), а также статус проблемы, а также любой форум, список рассылки, BTS или другие вещи, которые клиент или сторонники приводят к связыванию с этой проблемой. Это не должно быть каким -то новым вики или форумом сама по себе, просто фронт, связывающий и приклеивающий все вместе с метаданными по поводу этой проблемы. У него должен быть веб -интерфейс, похожий на BTS.
Проблемы и ошибки разные; Ошибки являются реальными проблемами в программном обеспечении, где проблемы чаще всего являются просто Pebcak или тому подобным. Вот почему необходимо создать новый трекер, потому что этот служит только для кратковременного отслеживания проблемы и убедиться, что он попадает в правильное окончательное место отдыха. Трекер предоставит боту и клиенту информацию, необходимую для создания фактоида в наших существующих информационных ботах, подать отчет об ошибке или выдать электронное письмо в списки рассылки и служить местом, где любая заинтересованная сторона может выяснить, какая из этих вещей произошла и где их найти. Это не замена, а обертка всех наших существующих систем. Это клей, который связывает все компоненты дисс, включая все, что у нас уже есть.
Много раз предполагалось, что мы просто улучшаем существующие системы, и это является частью этого, но это не вместо этого. У этого все равно будет проблема проблемы № 2, отчуждающего пользователей, потому что им нужно знать о том, как использовать эти вещи. Это было бы частью программного обеспечения в самой ОС, которая интегрирует и облегчает использование всего этого интуитивно понятным способом, который не требует года или более политики и практики обучения.
Что касается улучшения существующих систем, этот проект и его участники будут стремиться объединить регистрацию во всех и всех системах поддержки Debian, требующих регистрации, и работать с текущими командами этих систем, чтобы интегрировать их вместе в синергетическом виде.
Кроме того, существующие системы могут быть использованы/адаптированы при описании нынешних разработчиков, работающих в других областях, например, BTS и трекер могут быть одним и тем же, и эти «проблемы» могут быть просто более низким классом ошибки, с которым не беспокоится обслуживание, и отчет может быть просто расширен, чтобы включить эти другие функции, и существующий IRC BOT может быть внесен в модируемый и модифицирован, чтобы добавить необходимые функции. Это не просто проект, направленный на создание единого нового программного обеспечения, но адаптировать все, что у нас есть, чтобы лучше обслуживать нас в будущем.
Нам нужны программисты. Те, квалифицированные с Python, так как он кажется хорошо подходящим для этих задач, простых в кодировании и достаточно мощном и достаточно гибком, чтобы разрабатывать вещи, которые нам нужны, с меньшими зависимостями вне базовой системы. Те, квалифицированные с траст -системами и услугами, подписями GPG и т. Д. Те, кто знаком с процессом разработки Debian и всеми проблемами как пользователей, так и разработчиков. Те, кто может запрограммировать сетевые стеки клиентов/серверов, используя сокеты, HTTP, протоколы электронной почты и т. Д. Те, кто может разработать надежный API для эффективного общения систем поддержки Debian, что потребует знания для интеграции приложений в Интернете и за его пределами.
Нам нужен вклад и планирование вокруг наших существующих систем, усилия существующих команд и помощь им в том, чтобы включить единую систему учетных данных Debian Login, которая будет работать на всех сайтах и услугах Debian.
Нам нужны люди, которые будут работать над документированием и взаимодействием с присутствием в Интернете этого проекта, сохраняя информацию о статусе и целях проекта и такими четко определенными.
Этот проект только что начался в ранние утренние часы пятницы, 13 октября 2017 года, около 2 часов ночи США/EST. На момент написания этой статьи мы даже не в 24 часа, и у нас уже есть полдюжины или около того людей, болтающихся на канале, и ответы на различных форумах. На данный момент мы все просто лапше, бросая идеи и пытаемся тщательно принимать предварительные решения, которые будут формировать проект и его дизайн.
Первая цель здесь состоит в том, чтобы установить твердое присутствие в Интернете с вики и таким образом, что будет диаграмма анатомии этой интегрированной системы и ее прогресса, чтобы люди могли понять, откуда мы, куда мы идем и как далеко мы находимся.
Вторая цель здесь состоит в том, чтобы определить API, который будет определять функции и общение этой системы, и я не очень опытный программист, но я видел это на протяжении десятилетий, что иногда вам приходится делать что -то (инструмент), чтобы сделать что -то еще, и в этом случае я думаю, что начало работы над интерфейсом клиента, в частности, на фронта графического кампа И сначала без трекера проблемы, проблемы не будут настойчивы, это будет просто клиент, разговаривающий с элементарным ботом, который, вероятно, живет в нашем канале развития.
Следует подчеркнуть, что это не то, что мы хотим быстро вытащить и развернуть, мы хотим получить некоторую рабочую структуру и выполнять обширные альфа-тестирование вне обычных каналов, изначально без каких-либо изменений в существующих услугах, чтобы помочь облегчить интеграцию, поскольку API еще нет. После того, как у нас будут рабочие компоненты и интерес, а также тех, кто уже в рамках круга разработчиков Debian, мы хотели бы запустить фазу бета-тестирования только для использования только в непроизводственных тестировании/нестабильных системах. Как только появится уверенность в внедрении механизмов безопасного доверия для диагностики, система может быть фактически упакована для SID и, надеюсь, внедрена в будущий стабильный выпуск Debian. Файлы диагностики, скорее всего, будут использовать какой -то тип репозитория, который может позволить им разрабатывать их с течением времени и внедрить в клиент, не ожидая нового цикла выпуска Debian, основанного на отдельном жестком процессе тестирования и подписания/проверки.
В долгосрочной перспективе мы хотели бы, чтобы в качестве первого шага было более надежное определение навыков, более чем просто обычный/экспертный режим установки, и этот клиент -поддержка автоматически устанавливается по умолчанию в системах, не выбранных расширенным или экспертным уровням. Мы хотели бы, чтобы все наши сторонники участвовали не только в поддержке свободного воздействия, но и регистрируются в систему, основанную на доверии, и использовали подписи GPG, так что наша база знаний может быть более высоким качеством и более надежным.
Дисс вики
Reddit Thread
Форумы Debian Проходят
Поток списка рассылки Debian-Project
Поток списка рассылки Debian-Devel
Поток списка рассылки Debian-User
Связанный пост из списка рассылки Debian-Project в марте 2017 года