Hi all,
On Tue, 26 May 2026 at 08:28, Pjotr Prins <[email protected]> wrote:
[...]
Somehow, I agree with Pjotr’s words from [1]. Not fully, of course I’m
French after all ;-), bah some good topics for the next time we
meet. :-)
I’m a strong believer about this: a kind of truth emerges from polite,
civilized and respectful exchange of points of view. Then, once some
nets are well-identified, we should stay humble about our ability to
resolve all. Unity isn’t uniformity, IMHO. Somehow, the compass is
about what we can live with and what we cannot.
> I suggest we go with Christine's
> wording, leave out everything else on energy, evilness, worries of the
> future, etc. etc. All we should really care about is that no slop
> enters Guix and that people take ownership of what they do whatever
> way they go about it.=20
Somehow, I could live* with Christine’s wording or with André’s pledge,
both below for easy reading instead of the scattered wall of text. ;-)
*could live: modulo some minor tweaks.
Christine wrote [2]:
We do not use genAI to author core Guix itself. We ask that
contributors author patches themselves.
If contributors wish to use LLM tools to examine Guix, help them
debug, etc, this is their own choice. But the code they submit
should be their own. Even if you choose to talk to a chatbot,
type in the code yourself. This is important: the process of
doing so helps ensure we do not develop cognitive debt over our
codebase.
We do not use genAI for the reviews themselves. We don't
prohibit people from using genAI if they wanted to do a wide
triage of issues for instance; if they chose to use such a tool
to develop a list for themselves of low-hanging fruit, they
could. But the review should come from them, and use their
language, and their understanding. If we permit otherwise,
people will be demotivated from receiving automated reviews, and
will leave. I would.
What I suggest above permits some space for people to use
machine learning tools in their workflow of exploration, but not
in terms of authored contributions. While we cannot be sure, we
can make an ask of our contributors, and like the code of
conduct, it is something we can point to if we see something
going badly.
And André framed it this way [3]:
--8<---------------cut here---------------start------------->8---
1. Whenever Assistive Technologies were used, users MUST clearly state
it by the employment of tags such as 'Assisted-by: [technology
name]', 'Review-Assisted-by: [technology name]', 'Issue-found-by:
[technology name]' and Patch-Proposed-by: [technology name]'.
2. Assistive Technologies MUST NEVER be used directly to interact with
the project. As such, a user MUST NEVER simply paste answers,
patches, reviews or comments that were generated by Assistive
technologies without proper review or without their own input. Users
interacting with the project or with other users MUST ALWAYS be held
responsible for their inputs and the usage of Assistive Technologies
SHALL NEVER attenuate any improper behaviour.
3. Anyone found out to be using Assistive Technologies without complying
to the above conditions MAY be suspended from interacting with the
project for up to one year. Repeated violations of these duties SHALL
be considered grounds for a permanent ban proposal by any user which
SHALL be addressed and agreed upon by the consensus of the project
maintainers (team-maintainers) to come into effect.
4. Users, committers, maintainers and team members MAY accept to
interact with patches, issues or reviews that were generated with the
use of Assistive Technologies, at their discretion. Anyone MAY refuse
to interact with those by simply ignoring them. Pull Requests and
Issues that were opened with the assistance of these technologies and
that remain unanswered for more than 2 months MAY be closed without
further comments other than pointing to this clause.
5. Patches that were produced with Assistive technologies MAY be
accepted by Committers only on the 'gnu/packages' sub-hierarchy, at
their discretion.
6. Users proposing patches with the use of Assistive Technologies assume
complete and sole responsibility to any copyright, license or patent
claims that third parties may hold to it. Reviewers and Committers
are not expected to clear the legal situation on behalf of those
proposing them and their acceptance of any given patch MUST NEVER be
interpreted as legal aval.
7. Software packages that directly implement some Assistive Technologies
MAY be accepted to Guix where compatible with the project's free
software, code of conduct and package deprecation guidelines.
8. Software packages that accept the usage of Assistive Technologies on
their own development MAY be accepted for inclusion or maintenance in
Guix, even if their policy differs from ours, if they are compatible
with the project's free software, code of conduct and package
deprecation guidelines.
--8<---------------cut here---------------end--------------->8---
Cheers,
simon
1: [guix/guix-consensus-documents] 008-human-crafting.md: Add initial draft.
(PR #13)]
Pjotr Prins <[email protected]>
Tue, 26 May 2026 08:28:17 +0200
id:[email protected]
https://lists.gnu.org/archive/html/guix-devel/2026-05
https://yhetil.org/guix/[email protected]
2:
https://codeberg.org/guix/guix-consensus-documents/pulls/13#issuecomment-15774065
3:
https://codeberg.org/guix/guix-consensus-documents/pulls/13#issuecomment-15863315
