4.7 KiB
Contributing to PrivSec.dev
Thank you for your interest in contributing! In addition to standard GitHub etiquette, please follow these specific guidelines for contributing to PrivSec.dev.
Security Vulnerabilities
Please refer to the published Security Policy.
Post Contribution Guidelines
This section ("Post Contribution Guidelines") serves in part as a human‑readable summary of (but not a substitute for) the Contributor License Agreement, with supplementary information about contribution management policies. This section is not a license agreement and has no legal value. You should carefully review the terms and conditions of the actual Contributor License Agreement before agreeing to its terms and submitting a contribution.
All posts are submitted to PrivSec.dev under a Creative Commons Attribution‑ShareAlike 4.0 International License, which allows PrivSec.dev and downstream recipients to adapt and redistribute the work under the same license. Contributors retain copyright ownership and are free to do as they please with their own work, including posting to other websites and distribution under any license of their choosing. However, with limited exceptions, PrivSec.dev will not advertise other licenses or distribution channels.
PrivSec.dev places heavy emphasis on the autonomy of primary post authors (in most cases the original authors of posts). Whenever possible, primary post authors will be invited to review issues and pull requests seeking to update their work. However, the PrivSec.dev team reserves the right to both implement and reject changes at their sole discretion, including but not limited to cases of trivial fixes (e.g. typographical error correction), unsatisfactory change quality, removal of old/outdated information, and an unresponsive or unreachable primary post author.
If deemed necessary on a case‑by‑case basis, the PrivSec.dev team will archive and/or fork posts. This mechanism exists in part to avoid any perception that substantial changes to a post's content were written, approved, or endorsed by the primary post author when they in fact were not. In the event of a fork, relevant noteworthy contributors may be invited to assume the title of primary post author of the fork. If no suitable authorship agreement can be reached, the PrivSec.dev team shall retain editorial control while continuing to invite relevant contributors to review change proposals.
Any request which requires rewriting Git history will almost certainly be rejected. Rewriting history is an extremely disruptive, tedious, and sometimes error‑prone process which shall only be invoked in extenuating circumstances. Forks and local checkouts retain the original commit log anyway, so history rewriting is ineffective for any sort of data erasure. Please assume all contributions are logged forever (by someone even if not the PrivSec.dev team) and review your submissions carefully.
Corrections and Changes to Existing Posts
Issues and pull requests are both acceptable.
Pull requests are preferable for minor changes like correcting typographical errors or rewording to improve clarity.
For more substantial changes, consider opening an issue to discuss your proposal before doing significant work on it. We would hate for you to spend significant time creating a pull request only for it to be rejected or need major changes.
Note that we will likely defer you upstream in cases where PrivSec.dev mirrors an upstream version of a post. You are encouraged to proactively reach out to the upstream and open an issue here for tracking.
New Post Submissions and Requests
Please informally present your request/proposal with the maintainers in a discussion (preferred) or in the PrivSec.dev Matrix room, #PrivSec.dev:arcticfoxes.net. Research is expected to be well‑sourced with citations provided wherever applicable. If you are submitting content already written, feel free to directly open a pull request or draft pull request.
Website Configuration Issues and Enhancements
Please open an issue and provide as much detail as possible (screenshot, how to reproduce, browser and version, etc.). If the solution is exceedingly trivial, you may open a pull request directly, but we strongly encourage opening an issue first as some apparent issues may be deliberate.