Contributing

This page explains how to contribute useful work to 44Net docs and systems. It is for operators, maintainers, developers, and participants who want to help.

Why contribute

ARDC staff help produce documentation and maintain software tools, but the community is what keeps 44Net running and usable.

If you have a question, ask it. If you have an answer, share it. If you have a project writeup or lesson learned, post it. If you find a gap in the docs or a rough edge in a tool, fix it or help someone else fix it.

Many of the best improvements start the same way:

• someone runs into a real problem
• the answer is worked out in public
• the result is turned into documentation, code, or a better workflow

What kinds of contributions help

Useful contributions include:

• documenting a setup that actually works
• correcting outdated or incomplete wiki content
• improving examples, troubleshooting notes, and caveats
• contributing code to tools and infrastructure
• testing new features or configurations and reporting what happened
• helping others troubleshoot on the discussion groups
• sharing project writeups, lessons learned, and operating experience

Documentation

Documentation work is one of the highest-leverage ways to help.

If a recurring question appears on the mailing list or discussion group, consider converting the answer into a short wiki update. That keeps operational guidance searchable and reduces repeated troubleshooting cycles.

When contributing documentation:

• start with a specific gap from Getting started, Provisioning Methods, or a platform/setup page
• prefer small, verifiable updates over broad rewrites
• include concrete context such as device role, NAT posture, tunnel endpoint, routing behavior, and observed outcomes
• document caveats, rollback concerns, and anything still unverified
• write from actual tested experience where possible

For large or potentially contentious changes, it is often worth discussing them first in Community.

Software and tools

If you have software development experience and want to contribute code, there are several ways to help:

• propose a new tool or feature and discuss it in Community
• contribute to an existing project on GitLab
• improve small operational tools, scripts, and documentation helpers
• help test changes and report regressions or rough edges

If you want to contribute to an existing repository, check its contribution guidelines and open issues first. If the direction is unclear, start by asking in the relevant discussion space.

Other ways to participate

Not every contribution needs to be a wiki edit or a code change.

Other valuable ways to help include:

• testing configurations and reporting outcomes
• helping others troubleshoot their setups
• handling verification-related or administrative volunteer work where appropriate
• supporting community projects with time, equipment, hosting, or coordination
• building something useful and sharing it back with the rest of 44Net

Collaboration and feedback

In a contribution context, collaboration is about how work gets improved without creating churn.

The contributions that tend to stick are the ones that:

• solve a specific problem
• explain their scope and tradeoffs clearly
• stay open to correction and revision
• leave room for others to build on the result

When proposing or making changes:

• be explicit about what problem you are trying to solve
• distinguish tested facts from assumptions or preferences
• prefer incremental improvements over broad rewrites unless there is a clear reason not to
• share suggestions in a blameless way that focuses on the work, not the person
• respond to review with concrete adjustments, not defensiveness
• avoid presenting one setup, tool, or practice as the only valid approach unless policy or technical constraints require it

The goal is not consensus for its own sake. The goal is to produce work that is accurate, useful, reviewable, and maintainable.

Licensing

Material produced by ARDC staff is generally released under a Creative Commons Attribution-ShareAlike license (CC-BY-SA) or the non-commercial variant. ARDC-supported software projects are generally licensed under the Affero GNU General Public License (AGPL).

Others in the community may publish material under different licenses or according to different terms, but if those terms are not compatible with the CC-BY-SA license or the AGPL, that material should not be posted to this wiki or shared as an official 44Net resource. Here, we like to share work openly.

Related pages

• Community
• Governance
• Policies
• What People Build
• Getting started
• Routing and connectivity