Hi Gabriel,
Gabriel Wicki <[email protected]> writes:
Why would we suddenly opt for non-ideal "solutions" when (as I
perceive)
most people are not completely satisfied with the outcome?
Could you please explain what your perception is based on?
If most people were not satisfied, I’d expect to see objective
evidence of it, in forms like:
- Most votes being "I accept" or "I disagree."
- Replies to your disagreement which support the points you raise
as issues needing resolution.
- Replies to your disagreement supporting it overall, even if not
sharing the specific points of objection.
I don’t see any of that. Most votes are in support, with many
expressing what I would characterize as enthusiastic support ("I
support!" with an exclamation point). The replies to your
disagreement have sought to understand it, but I haven’t seen
anyone supporting either the points you raise or the overall
objection.
Addressing your points directly:
1. From the project perspective: Discussions continued way into
the
deliberation period: the proposal could use some more time to
(at least)
smooth the rough edges.
2. Consent-wise: Time-pressure and an overwhelming amount of FUD
grossly
contradict my understanding of consent.
2. I just don't buy the "if we don't regulate it now it will be
too late
and Guix is doomed forever" argument.
These are objections to the process, not the outcome. I fully
agree that this has been a messy GCD, directly following another
messy GCD, and that’s sufficient evidence to justify finding
better ways to manage the process. But I don’t see how blocking
this GCD accomplishes that, nor do I think a better-managed
process would produce a materially better document in this case.
3. From a community perspective: I don't think it is appropriate
to
craft contribution guidelines as a by-product of the LLM
discussion.
Given that we need both, but have neither, what’s the benefit of
doing them in your suggested order vs. the opposite? What are the
downsides of doing them in this order?
If these are separate discussions, and contribution guidelines
must happen first, would that mean producing contribution
guidelines which do not contemplate LLM contributions?
To my mind, these conversations are inextricably linked.
Contribution guidelines which don’t address LLM contributions
feels like it’d fit the same "non-ideal" characterization you give
this GCD; and one cannot adopt *any* policy on LLM contributions
without it interacting with some contribution guidelines.
4. Quality of the document: It is still rather unclear in a few
areas.
If these points are addressed, is that sufficient for you to
support the GCD? If not, what else would it take?
5. Technically: The (please excuse the potentially wrong label)
"Luddite" angle ("these tools hurt real craftspersonship") seems
to be
historically wrong, in a way that is ignorant in how progress
works in
the tech world.
5. The "Luddite" angle reminds me of how people have probably
argued
back in the 80ies, when general purpose C compilers took away
the jobs
of the crafty assembly programmers. With—I guess—mostly similar
arguments. And while it is still true that *real, fast code*,
which
people understand and can translate to what the machine actually
does,
is written in assembler¹ it is without doubt that we are
generally happy
not having to write code at instruction level.
The history of our Free Software movement has shown how we roll,
again
and again: Tools get invented and when they prove useful the
technology
providing the tools gets liberated (by us, the movement). This
is how
GCC came to dominate and extinguish many other compilers, how
GNU+Linux
distros replaced (almost) all the Unices, how ... you get the
idea.
Without adequately defining *what exactly* we are banning or
restricting, thus by accepting this GCD, we burden ourselves to
another
one of these absolutely nerve-wrecking processes.
What, specifically, would resolve this concern for you? Does this
boil down to a reiteration of "The term genAI is not (properly)
defined?" Do you object to the GCD title?
-- Ian
[1]: https://en.wikipedia.org/wiki/Consensus
[2]: The GCD process also handles this poorly, in my opinion, as
it calls the process "consensus," but the actual measure is
"unanimity."
[3]: https://en.wikipedia.org/wiki/Consent
