{{Header}} {{title|title= Development Discussion Policy }} {{#seo: |description=Explains why certain technical topics are not open for discussion with non-developers, ensuring development focus, security, and maintainability. }} {{policy_mininav}} {{intro| Clarifies that some technical topics are not suitable for discussion with non-developers, helping maintain project focus and sustainability. }} = Introduction = Some feature requests, security topics, and policy discussions are highly technical and not productive to discuss with non-developers. Clearly, a project must remain focused and say no to certain ideas. That is why there is a large number of [[Project Policies]]. Additionally, extended debates on fundamental principles, technical design, and implementation details with non-developers are often counterproductive. These can cause overhead, which means spending more time on discussion while making less development progress. For the purpose of [[Dev/maintainability|maintainability]], some discussions are limited to developers only. Some discussions may even be open only to (active) source code contributors. This wiki page documents the Development Discussion Policy. = Development Discussion Policy = At the discretion of core developers, certain discussions may be limited or closed when they are deemed unproductive, off-topic, or excessively time-consuming relative to the benefit they provide. Some areas that may be restricted from general discussion include, but are not limited to: * Fundamental architectural decisions * Security design * Feature rejections already explained in existing [[Project Policies]] * Development processes and tooling * Topics repeatedly raised without new deep technical insights Core developers may: * Lock development forum and issue tracker conversations * Close pull requests or issues that devolve into prolonged debate without clear technical benefit * Request that only active contributors participate in sensitive or advanced topics Those who wish to influence technical direction are expected to demonstrate sustained source code contributions that require programming skills, familiarity with the project's codebase, goals and policies. Is similar to [[First Time Source Code Contributor Policy]]. = Rationale = One cannot educate oneself based on news alone. News focuses on sensational, exceptional, negative, and current events. Relying solely on it leads to a lack of foundational knowledge. Medical analogy: To research and contribute to improved heart surgery procedures, one must be a heart surgeon (or another qualified medical researcher). For example, someone not active in this field cannot speak with certainty or demand that heart surgeons change their procedures. {{quotation |quote=Non-technical users lack foundations. They cannot inspect architecture, threat models, or source code. |context=[[System Audit]] wiki page. }} These decisions are not made arbitrarily. They exist to: * Protect the limited time of core developers * Avoid re-litigating decisions that have already been made after careful technical consideration * Prevent distraction from mission-critical development work * Reduce the volume of non-actionable commentary that hinders issue tracker usability Please note that this policy does not discourage questions, feedback, or participation from users. Rather, it sets expectations about where and how certain technical conversations can occur for the sake of project [[Dev/maintainability|maintainability]] and long-term sustainability. = Related = * [[Reporting_Bugs#Community_Feedback|Community Feedback]] * [[Reporting_Bugs#Contributions|Contributions]] = Similar Practices in Open Source Projects = Many Open Source projects deliberately separate developer discussions from general user input to maintain efficiency and protect against security or maintenance issues. Here are some examples from real Open Source projects and developer communities that maintain similar policies, where technical decisions or deeper discussions are restricted to developers, and not open for general or non-technical conversation: * '''Debian Project:''' Only vetted contributors (Debian Developers) are granted voting rights and decision-making privileges under the Debian Constitution. [https://www.debian.org/devel/join/ Debian Project – How to Become a Developer] * '''Open Source Governance Principles:''' Projects often define clear contributor roles (e.g. committers, maintainers) to ensure that only trusted, technically capable individuals guide the project. [https://opensource.guide/leadership-and-governance/ Open Source Guide – Leadership and Governance] * '''On Rejecting Unsustainable Contributions:''' Experienced maintainers commonly reject well-meaning contributions if they impose long-term maintenance costs or misalign with project goals. [https://news.ycombinator.com/item?id=25940195 Hacker News – Discussion on Maintaining Healthy OSS Projects] * '''Contribution Filtering and Project Vision:''' Even popular projects routinely reject pull requests that don’t match their architecture, goals, or maintainability expectations. [https://opensource.stackexchange.com/questions/15059/what-are-my-options-if-an-open-source-project-rejects-my-changes Open Source StackExchange – On Rejected Contributions] {{quotation |quote=The issue tracker is a tool to help the developers be more productive and efficient in their work. It is not a place for discussion.
This guideline is important for keeping issues focused on actionable information, which helps the developers to stay focused on their work. When developers come back to an issue to work on it, we do not want them to have to sift through a large number of unnecessary comments before they can get started. In many cases, an issue that gets “too big” essentially becomes more trouble than it’s worth, and no developer will touch it (also see every issue must be about a single, actionable thing). In these cases, we sometimes have to close the issue and open a new one. This is a waste of energy for everyone involved, so we ask that everyone help to avoid repeating this pattern. |context=Qubes issue tracker FAQ: [https://www.qubes-os.org/doc/issue-tracking/#the-issue-tracker-is-not-a-discussion-forum The issue tracker is not a discussion forum] }} {{quotation |quote=This conversation has been locked and limited to collaborators. |context=https://github.com/systemd/systemd systemd] [https://github.com/systemd/systemd/issues issue tracker] * [https://github.com/systemd/systemd/issues/33349 refuse systemd-tmpfiles --purge invocation without config] * [https://github.com/systemd/systemd/issues/33760 Boot hangs due to systemd-networkd-wait-online.service] * [https://github.com/systemd/systemd/issues/32028 Reduce dependencies of libsystemd] * [https://github.com/systemd/systemd/issues/26312 Many Failures on services when /home symlinked to non-…] * [https://github.com/systemd/systemd/issues/18014 Allow disabling systemd-sysv-generator warnings about …] * [https://github.com/systemd/systemd/issues/9894 Remove offensive words from code] * [https://github.com/systemd/systemd/issues/6237 systemd can’t handle process privilege with username starting with a number] * [https://github.com/systemd/systemd/issues/1741 systemd umounts manual mounts when it has a failed unit for that mount point] * [https://github.com/systemd/systemd/issues/2402 Mount efivarfs read-only] * [https://github.com/systemd/systemd/issues/1143 PID1 getting stuck printing “Time has been …”] * [https://github.com/systemd/systemd/issues/14897 docs: Consider building the site with GFM instead of Kramdown] * more tickets for similar projects can be found with the following AI search query: {{CodeSelect|code= site:https://github.com/systemd/systemd find links to tickets which are open for discussion by collaborators only }} }} Other projects often close discussions to non-collaborators without providing an explanation. In some projects, the developers tend to stay largely away from the forums. = Footnotes = {{reflist|close=1}} {{Footer}} [[Category:Development]] [[Category:MultiWiki]]