Development Discussion Policy
Donate
This navigation is a compilation of Whonix project policies.
- Project Policies
- Policy of Website and Chat
- Policy On Nonfreedom Software
- Policy On Artificial Intelligence (AI)
- Wiki Editing Policy
- Wiki Comments Policy
- First Time Source Code Contributor Policy
- Development Discussion Policy
- Limitations on Free Speech on Website and Chat
- Transparency, Sponsors / Advertisement Policy
Clarifies that some technical topics are not suitable for discussion with non-developers, helping maintain project focus and sustainability.
Introduction
[edit]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 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 Participation Policy
[edit]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 for Development Discussion Participation Policy
[edit]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.
Non-technical users lack foundations. They cannot inspect architecture, threat models, or source code.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 maintainability and long-term sustainability.
Related
[edit]Similar Practices in Open Source Projects
[edit]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. [1]
- 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. [2]
- On Rejecting Unsustainable Contributions: Experienced maintainers commonly reject well-meaning contributions if they impose long-term maintenance costs or misalign with project goals. [3]
- Contribution Filtering and Project Vision: Even popular projects routinely reject pull requests that don’t match their architecture, goals, or maintainability expectations. [4]
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.Qubes issue tracker FAQ: The issue tracker is not a discussion forum
This conversation has been locked and limited to collaborators.https://github.com/systemd/systemd
systemd] issue tracker
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.
Development Discussion Expectations
[edit]- Reasonably read the full discussion.
- Follow a reasonable number of relevant links.
- This includes following links found within other linked pages, up to a reasonable depth, without getting caught in an infinite loop.
rationale:
- Preserve developer time.
- Avoid off-topic discussion.
- Avoid circular arguments.
Footnotes
[edit]- ↑
Debian Project – How to Become a Developer
- ↑
Open Source Guide – Leadership and Governance
- ↑
Hacker News – Discussion on Maintaining Healthy OSS Projects
- ↑
Open Source StackExchange – On Rejected Contributions
- ↑
- refuse systemd-tmpfiles --purge invocation without config
- Boot hangs due to systemd-networkd-wait-online.service
- Reduce dependencies of libsystemd
- Many Failures on services when /home symlinked to non-…
- Allow disabling systemd-sysv-generator warnings about …
- Remove offensive words from code
- systemd can’t handle process privilege with username starting with a number
- systemd umounts manual mounts when it has a failed unit for that mount point
- Mount efivarfs read-only
- PID1 getting stuck printing “Time has been …”
- docs: Consider building the site with GFM instead of Kramdown
- more tickets for similar projects can be found with the following AI search query: site:https://github.com/systemd/systemd find links to tickets which are open for discussion by collaborators only
- refuse systemd-tmpfiles --purge invocation without config
The most watertight privacy operating system in the world.
At
Whonix we value freedom and trust, supporting Open Source and Freedom Software
2012-
2025 ENCRYPTED SUPPORT LLC
We believe security software like Whonix needs to remain open source and independent. Would you help sustain and grow the project? Learn more about our 13 year success story and maybe DONATE!