05.07.26
51
Администратор, Модератор, Security Researcher, Social Engineer, VPN Overlord, Recruiter
0
ПРАВИЛА РАЗДЕЛА «ПРОГРАММИРОВАНИЕ И РАЗРАБОТКА»
1. Подраздел «Запросы на разработку» (Коммерция)
1.1. Четкое Техническое Задание (ТЗ). Заказчик обязан максимально подробно описать задачу:
Цель работы (десктопное приложение, телеграм-бот, парсер, веб-сервис, API-интеграция и т.д.).
Стек технологий (язык программирования, фреймворки, база данных), который должен использовать разработчик.
Технические требования (нагрузка, скорость, многопоточность, совместимость с ОС).
Ожидаемый результат (исходный код, скомпилированный файл, инструкция по развертыванию).
1.2. Примерный бюджет. Указывайте вилку бюджета (например, 500–1000$). Темы с формулировками «Дорого», «Бюджет договорный» или без указания цены могут быть закрыты модератором до внесения корректировок.
1.3. Гарант. Все финансовые расчеты между заказчиком и исполнителем проводятся строго через систему «Гарант» или биржу форума. Сделки вне гаранта — на свой страх и риск, споры по ним администрацией не рассматриваются.
1.4. Передача прав. В теме обязательно указывайте, переходит ли исключительное право на код к заказчику или код предоставляется с лицензией на использование (без права перепродажи). Если это не указано — по умолчанию право остается у разработчика.
1.5. Этапы и приемка. Рекомендуется разбивать крупные проекты на этапы. Заказчик не имеет права требовать полный код до финальной оплаты, а исполнитель не имеет права получать полную оплату до сдачи итогового рабочего продукта.
1.6. Запрет на перепродажу. Исполнителям запрещено передавать заказчику чужой код (с открытых репозиториев или купленный ранее) под видом собственной уникальной разработки. Это карается штрафом и потерей статуса.
2. Подраздел «Бесплатные скрипты, софты, утилиты» (Публикации для всех)
2.1. Проверка на вирусы. Любой загружаемый файл (архив, .exe, .scr, .js, .vba) обязан сопровождаться ссылкой на проверку через VirusTotal или аналогичный сервис (с результатами сканирования). Администрация оставляет за собой право удалить файл без проверки.
2.2. Открытый исходный код (рекомендовано). Для повышения доверия к бесплатным утилитам настоятельно рекомендуется выкладывать исходный код (хотя бы основные модули) в текст темы или на GitHub/GitLab. Исполняемые файлы без исходников принимаются только от проверенных держателей статуса «Программист» со стажем более 6 месяцев.
2.3. Описание функционала. Автор обязан подробно расписать:
Для чего нужна утилита.
Инструкцию по установке и запуску.
Системные требования (версия ОС, наличие .NET, Java, Python и т.д.).
Скриншоты интерфейса или примеры работы.
2.4. Запрет на скрытые функции. Категорически запрещено встраивать в бесплатный софт скрытый сбор данных (телеметрию без согласия пользователя), майнеры, бэкдоры или рекламный софт (adware). За нарушение — перманентный бан.
2.5. Сборка и зависимости. Если утилита использует сторонние библиотеки, автор обязан указать все зависимости в отдельном файле (requirements.txt, package.json и т.п.).
2.6. Поддержка. Публикуя софт бесплатно, автор не обязан оказывать круглосуточную поддержку, однако обязан в течение 72 часов ответить на вопросы по установке, если они возникли у пользователей в течение первой недели после публикации.
2.7. Архивация. Если ссылка на скачивание ведет на сторонний файлообменник — срок хранения файла должен быть не менее 30 дней. Ссылки, ведущие на удаленные файлы, будут закрыты с занесением в предупреждения автору.
3. Дополнительные технические и этические пункты (ДОБАВЛЕНЫ)
3.1. NDA (Соглашение о неразглашении). Если в процессе разработки заказчик передает разработчику базы данных, логины, коммерческую тайну — стороны обязаны подписать цифровое соглашение до начала работ, иначе администрация не несет ответственности и не будет наказывать стороны за разглашение конфиденциальной информации на просторах интернета. Передача чувствительных данных через ЛС форума запрещена (используйте PGP или шифрованные мессенджеры).
3.2. Демонстрация кода. Исполнитель может показывать фрагменты кода в теме для подтверждения своих навыков, но не обязан выкладывать финальный продукт в открытый доступ до оплаты.
3.3. Сроки. В коммерческих запросах исполнитель обязан указать реалистичные сроки сдачи. Просрочка более чем на 7 дней без уважительной причины дает право заказчику расторгнуть сделку через гаранта с возвратом средств.
3.4. Техническая поддержка после сдачи. По умолчанию разработчик обязан исправлять критические баги, обнаруженные в течение 2 недель после приемки, бесплатно (если иное не оговорено в ТЗ).
3.5. Запрет на плагиат. При публикации бесплатных скриптов, основанных на чужих наработках, обязательно указывать автора оригинального кода и лицензию (MIT, GPL, Apache и т.д.). Нарушение авторских прав влечет удаление темы и лишение статуса.
1. Подраздел «Запросы на разработку» (Коммерция)
1.1. Четкое Техническое Задание (ТЗ). Заказчик обязан максимально подробно описать задачу:
Цель работы (десктопное приложение, телеграм-бот, парсер, веб-сервис, API-интеграция и т.д.).
Стек технологий (язык программирования, фреймворки, база данных), который должен использовать разработчик.
Технические требования (нагрузка, скорость, многопоточность, совместимость с ОС).
Ожидаемый результат (исходный код, скомпилированный файл, инструкция по развертыванию).
1.2. Примерный бюджет. Указывайте вилку бюджета (например, 500–1000$). Темы с формулировками «Дорого», «Бюджет договорный» или без указания цены могут быть закрыты модератором до внесения корректировок.
1.3. Гарант. Все финансовые расчеты между заказчиком и исполнителем проводятся строго через систему «Гарант» или биржу форума. Сделки вне гаранта — на свой страх и риск, споры по ним администрацией не рассматриваются.
1.4. Передача прав. В теме обязательно указывайте, переходит ли исключительное право на код к заказчику или код предоставляется с лицензией на использование (без права перепродажи). Если это не указано — по умолчанию право остается у разработчика.
1.5. Этапы и приемка. Рекомендуется разбивать крупные проекты на этапы. Заказчик не имеет права требовать полный код до финальной оплаты, а исполнитель не имеет права получать полную оплату до сдачи итогового рабочего продукта.
1.6. Запрет на перепродажу. Исполнителям запрещено передавать заказчику чужой код (с открытых репозиториев или купленный ранее) под видом собственной уникальной разработки. Это карается штрафом и потерей статуса.
2. Подраздел «Бесплатные скрипты, софты, утилиты» (Публикации для всех)
2.1. Проверка на вирусы. Любой загружаемый файл (архив, .exe, .scr, .js, .vba) обязан сопровождаться ссылкой на проверку через VirusTotal или аналогичный сервис (с результатами сканирования). Администрация оставляет за собой право удалить файл без проверки.
2.2. Открытый исходный код (рекомендовано). Для повышения доверия к бесплатным утилитам настоятельно рекомендуется выкладывать исходный код (хотя бы основные модули) в текст темы или на GitHub/GitLab. Исполняемые файлы без исходников принимаются только от проверенных держателей статуса «Программист» со стажем более 6 месяцев.
2.3. Описание функционала. Автор обязан подробно расписать:
Для чего нужна утилита.
Инструкцию по установке и запуску.
Системные требования (версия ОС, наличие .NET, Java, Python и т.д.).
Скриншоты интерфейса или примеры работы.
2.4. Запрет на скрытые функции. Категорически запрещено встраивать в бесплатный софт скрытый сбор данных (телеметрию без согласия пользователя), майнеры, бэкдоры или рекламный софт (adware). За нарушение — перманентный бан.
2.5. Сборка и зависимости. Если утилита использует сторонние библиотеки, автор обязан указать все зависимости в отдельном файле (requirements.txt, package.json и т.п.).
2.6. Поддержка. Публикуя софт бесплатно, автор не обязан оказывать круглосуточную поддержку, однако обязан в течение 72 часов ответить на вопросы по установке, если они возникли у пользователей в течение первой недели после публикации.
2.7. Архивация. Если ссылка на скачивание ведет на сторонний файлообменник — срок хранения файла должен быть не менее 30 дней. Ссылки, ведущие на удаленные файлы, будут закрыты с занесением в предупреждения автору.
3. Дополнительные технические и этические пункты (ДОБАВЛЕНЫ)
3.1. NDA (Соглашение о неразглашении). Если в процессе разработки заказчик передает разработчику базы данных, логины, коммерческую тайну — стороны обязаны подписать цифровое соглашение до начала работ, иначе администрация не несет ответственности и не будет наказывать стороны за разглашение конфиденциальной информации на просторах интернета. Передача чувствительных данных через ЛС форума запрещена (используйте PGP или шифрованные мессенджеры).
3.2. Демонстрация кода. Исполнитель может показывать фрагменты кода в теме для подтверждения своих навыков, но не обязан выкладывать финальный продукт в открытый доступ до оплаты.
3.3. Сроки. В коммерческих запросах исполнитель обязан указать реалистичные сроки сдачи. Просрочка более чем на 7 дней без уважительной причины дает право заказчику расторгнуть сделку через гаранта с возвратом средств.
3.4. Техническая поддержка после сдачи. По умолчанию разработчик обязан исправлять критические баги, обнаруженные в течение 2 недель после приемки, бесплатно (если иное не оговорено в ТЗ).
3.5. Запрет на плагиат. При публикации бесплатных скриптов, основанных на чужих наработках, обязательно указывать автора оригинального кода и лицензию (MIT, GPL, Apache и т.д.). Нарушение авторских прав влечет удаление темы и лишение статуса.