From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; dkim=pass header.d=meshpointone.com header.i=@meshpointone.com header.a=rsa-sha256 header.s=key1 header.b=CxETtd2x; arc=none (Message is not ARC signed); dmarc=pass (Used From Domain Record) header.from=meshpointone.com policy.dmarc=none Received: from mta0.migadu.com (out-237.mta0.migadu.com [IPv6:2001:41d0:1004:224b::ed]) by mail.toke.dk (Postfix) with ESMTPS id 200851950381 for ; Fri, 30 Oct 2026 16:12:03 +0100 (CET) X-Envelope-To: galene@lists.galene.org DKIM-Signature: a=rsa-sha256; bh=QDCZDP6ti8KvQNmgn7zM9gdqdkFpTKp49Ok4NjwEj/o=; c=simple/simple; d=meshpointone.com; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1793373122; v=1; x=1793977922; b=CxETtd2x+27XpWL6ILd/KT/3oyNtk1GWaH+g1i3oo0bJ4SGj+7aevCjXTBiuOrdVfmfeJWpI wt30UZU9eNevoCd+hE3tOVdC8Abpjoq5XQM0IVyDGLlSl+5QSx327b9eoiRUMyMq856eThKB7sW /rPy3ttD8zNcsILv4ODg/Ju5MsVfgplRc/rm6K+VQOMMJ1w7ac/RWZE7oaXJ60zNt3+hskJGrck PUkPSavfmmNzOI/HgYFxlVQpWB239vHIY9VGaSz4n5FMZorE9LHd6BPY2NJM2dnXsx0wQHmybpF BYTIQyUUdw++f76HmOtZlc3bwdGHNkDiRU7Qmw3I9UApA== X-Envelope-To: galene@lists.galene.org Received: by smtp.migadu.com with ESMTPS id fc7718a1d5b87bcd; Fri, 30 Oct 2026 15:12:01 +0000 X-Mizu-Trace-ID: fc7718a1d5b87bcd X-Migadu-Flow: FLOW_OUT From: "Valent@MeshPoint" To: "galene@lists.galene.org" Date: Fri, 30 Oct 2026 15:11:59 +0000 Message-Id: User-Agent: eMClient/11.0.0.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB71CB0A18-D81C-4B8D-AFCD-5ACF23F05AA1" Message-ID-Hash: 4LGQ5CMYIYEP2XBKMNBWTNB66PDXFJI6 X-Message-ID-Hash: 4LGQ5CMYIYEP2XBKMNBWTNB66PDXFJI6 X-MailFrom: valent@meshpointone.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Reply-To: "Valent@MeshPoint" Subject: [Galene] [RFC] Contributing guidelines[RFC] Contributing guidelines List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --------=_MB71CB0A18-D81C-4B8D-AFCD-5ACF23F05AA1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I could find no written rules for contributors, so new contributors (me=20 included) keep making the same mistakes in PRs. I collected what=20 Juliusz wrote about this in reviews on the list and on GitHub since=20 2020, and put it into the draft below. Comments are welcome. A few things I could not find: 1. Is a short first line enough for a commit message, or do you want a=20 body too? 2. Is there a style for Go, CSS and JS beyond the surrounding code? 3. What testing do you expect for UI changes? 4. Should this be a CONTRIBUTING.md file, or a section of the README? Thanks, -- Valent # Contributing to Galene Galene is distributed under the MIT licence, and all contributions are published under the same licence. No CLA is required. ## Where to send You may either send patches to the mailing list , or submit a pull request on GitHub. Please use one or the other, not both. General and technical discussion belongs on the mailing list, not on GitHub. Bug reports go to GitHub issues. Ideas are welcome, even if they are not accompanied with patches. ## What is likely to be accepted Galene is meant to be easy to install and to have minimal dependencies. Before writing a large feature, please ask on the list. - Respect user privacy. Contributions that expose private user data, such as IP addresses or user names, will not be accepted. - Don't harm performance, especially in the server. - Avoid heavy libraries, unless they are loaded lazily. Anything that requires an external daemon (e.g. an SQL server) is out of the question. - Explain what problem the change solves. Once a feature is included, it is difficult to remove, so only features that are actually needed are included. Please don't be discouraged if your first attempt is not accepted. ## Preparing a pull request - Use a dedicated branch for each pull request, based on current master. - Every commit should be a self-contained change. Unrelated changes=20 go into a separate pull request. - Every commit must compile and must not break any functionality. - No merge commits. Rebase on master instead. - Squash your work-in-progress commits before submitting (use `git rebase -i`). When you fix something during review, squash the fix into the commit it belongs to. - Don't leave commented-out code. - Remove "WIP" from the title when the pull request is ready for=20 review. ## Commit messages The first line is a short summary of what the commit does, starting with a verb and ending with a period: Handle overflow in the user list. If needed, add a blank line and a short paragraph that explains the problem and the solution. Don't describe the history of the pull request. A verbose commit message is not more useful than a short one. ## Code - Follow the style of the surrounding code. - Add tests for server code where it makes sense. - The JavaScript code is checked with the TypeScript compiler. Please check your changes with `tsc` before submitting. - Comments should explain why, not what. Don't paraphrase the code=20 and don't repeat the documentation; such comments get out of sync when the code changes. - Prefer short, simple code. Code that is verbose or redundant is=20 hard to review and hard to maintain. - In the client, avoid making the logic depend on details of the user interface. ## Review Please answer questions during review. Pull requests without a reply from the submitter are eventually closed. --------=_MB71CB0A18-D81C-4B8D-AFCD-5ACF23F05AA1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,

I could find no written rules for contribut= ors, so new contributors (me included) keep making the same mistakes in PRs= .=C2=A0 I collected what Juliusz wrote about this in reviews on the list an= d on GitHub since 2020, and put it into the draft below.=C2=A0
Commen= ts are welcome.

A few things I could not find:

1. Is= a short first line enough for a commit message, or do you want=C2=A0a body= too?

2. Is there a style for Go, CSS and JS beyond the surroundi= ng code?

3. What testing do you expect for UI changes?
4. Should this be a CONTRIBUTING.md file, or a section of the README?
Thanks,

-- Valent

# Contributing to Galene

Galene is distributed under the MIT licence, and all contributions = are
published under the same licence.=C2=A0 No CLA is required.
=
## Where to send

You may either send patches to the mailin= g list
<galene@lists.gal= ene.org>, or submit a pull request on GitHub.=C2=A0 Please
use= one or the other, not both.

General and technical discussion bel= ongs on the mailing list, not on
GitHub.=C2=A0 Bug reports go to GitHu= b issues.=C2=A0 Ideas are welcome, even if
they are not accompanied wi= th patches.

## What is likely to be accepted

Galene i= s meant to be easy to install and to have minimal dependencies.
Before = writing a large feature, please ask on the list.

=C2=A0 - Respe= ct user privacy.=C2=A0 Contributions that expose private user data,
= =C2=A0 =C2=A0 such as IP addresses or user names, will not be accepted.=C2=A0 - Don't harm performance, especially in the server.
=C2=A0 -= Avoid heavy libraries, unless they are loaded lazily.=C2=A0 Anything that=C2=A0 =C2=A0 requires an external daemon (e.g. an SQL server) is out o= f the
=C2=A0 =C2=A0 question.
=C2=A0 - Explain what problem the c= hange solves.=C2=A0 Once a feature is included,
=C2=A0 =C2=A0 it is di= fficult to remove, so only features that are actually needed
=C2=A0= =C2=A0 are included.

Please don't be discouraged if your first att= empt is not accepted.

## Preparing a pull request

=C2= =A0 - Use a dedicated branch for each pull request, based on current
= =C2=A0 =C2=A0 master.
=C2=A0 - Every commit should be a self-contained = change.=C2=A0 Unrelated changes go
=C2=A0 =C2=A0 into a separate pull = request.
=C2=A0 - Every commit must compile and must not break any fu= nctionality.
=C2=A0 - No merge commits.=C2=A0 Rebase on master instead= .
=C2=A0 - Squash your work-in-progress commits before submitting (use=
=C2=A0 =C2=A0 `git rebase -i`).=C2=A0 When you fix something during r= eview, squash the
=C2=A0 =C2=A0 fix into the commit it belongs to.=C2=A0 - Don't leave commented-out code.
=C2=A0 - Remove "WIP" from= the title when the pull request is ready for review.

## Commit m= essages

The first line is a short summary of what the commit doe= s, starting with
a verb and ending with a period:

=C2=A0= =C2=A0 Handle overflow in the user list.

If needed, add a blank li= ne and a short paragraph that explains the
problem and the solution.= =C2=A0 Don't describe the history of the pull
request.=C2=A0 A verbose = commit message is not more useful than a short one.

## Code
=C2=A0 - Follow the style of the surrounding code.
=C2=A0 - Ad= d tests for server code where it makes sense.
=C2=A0 - The JavaScript= code is checked with the TypeScript compiler.=C2=A0 Please
=C2=A0 =C2= =A0 check your changes with `tsc` before submitting.
=C2=A0 - Comments = should explain why, not what.=C2=A0 Don't paraphrase the code and
=C2= =A0 =C2=A0 don't repeat the documentation; such comments get out of sync wh= en
=C2=A0 =C2=A0 the code changes.
=C2=A0 - Prefer short, simple= code.=C2=A0 Code that is verbose or redundant is hard
=C2=A0 =C2=A0 to = review and hard to maintain.
=C2=A0 - In the client, avoid making the = logic depend on details of the user
=C2=A0 =C2=A0 interface.

## Review

Please answer questions during review.=C2=A0 Pull r= equests without a reply
from the submitter are eventually closed. --------=_MB71CB0A18-D81C-4B8D-AFCD-5ACF23F05AA1--