On 2026-11-02 at 01:23, Simon Richter wrote: > Hi, > > On 11/1/26 08:46, Thomas Goirand wrote: > >> we're giving you a tool. > > I do not want that tool, yet it has been decided that uploading a > package to NEW triggers precious resources to be wasted on my behalf, > and the only agency I have left is to decide whether I want to also > discard the result of this, making the waste of resources truly > pointless, or agree that this waste is truly inevitable and make the > best of it by at least utilizing the results. > > The people responsible for this waste have agency and personal > responsibility, and they have decided that generating these messages > is a good use of resources. That is their prerogative, and it > certainly informs my opinion of them, but I cannot control their > actions, nor should I be able to. > > I am therefore exercising the bit of agency I have left, and will not > upload to NEW until this is fixed. Fortunately, not too many of my > packages are affected.
I have been reading the discussion, and noticing what looks to me like a key aspect of the perspective of at least some of the people who have objections to the "uploads to NEW automatically trigger LLM processing" change which those defending that change do not appear to be addressing. That perspective appears to be represented fairly explicitly in the above, but I think the aspect I've been noticing may still not be explicitly clear - and if I'm right both about what it is and that it is key to the perspective, I think it may be worth addressing directly. To my eye, it looks as if the key issue here - in conjunction with, as the mail above makes explicit, agency - is the automation. If the situation were "I upload a package to NEW, and a member of the DFSG team looks at that package and decides whether or not to have a LLM process it", the decision of whether to invoke the costs (in whatever form they may take) of LLM use would rest with the member of the DFSG team in question. There would be a layer of remove between the agency and action of the uploader, and the initiation of the LLM activity: the DFSG-team member deciding "I am going to work on this package, and this is one of the tools I am going to use in order to do so". With the situation of "I upload a package to NEW, and it is automatically processed by a LLM", that layer of remove is not present. The final decision which triggers the LLM activity is that of the uploader; in effect, the decision to upload is thereby a decision to include that LLM in the tools the uploader is using. The only way the uploader can choose not to make the latter decision is to also choose not to upload to NEW. The locus of where the decision is made is, I think, what makes this a matter of agency and responsibility. Having the LLM processing be automatic places that agency and that responsibility on the shoulders of the uploader; having it be something invoked by the members of the DFSG team individually on a per-package basis (or not, if a particular team member does not feel a need for doing it in a particular instance) places those things on the shoulders of those team members. To wave objections away as "just don't use the output, then" (whether in the form of ignoring the mail with that output, or in the form of having a preference option for the mail not even being sent) is to disregard the fact that for some people who choose not to use LLMs, part of the reason for that decision is that the costs of *having the LLM process anything* are higher than they see as being warranted, and they do not wish to be the initiating factor for any such activity. A definition of "using a LLM" which says "if you don't see the output, you aren't using the LLM" disregards that question of costs, even though for some people that question is the critical one. (There is probably room for at least an entire other mail, and possibly an entire discussion thread, about exactly what the definition of "use" is and/or should be when it comes to LLMs; that might also be relevant to understanding the disagreements between the sides of this discussion. In the interest of avoiding distraction, however, I am choosing not to get into that any deeper for the moment.) It is normally my position that "computers are for automation", and "if you have a set of steps to be performed on a computer, over and over and over again in exactly the same way, and you *aren't* automating them, you are Doing It Wrong". The initiation of LLM processing of an uploaded package could be seen as being one such set of steps - but when the performing of the steps is itself controversial, that seems to bring the matter outside of the scope of that position, from the technical arena into the interpersonal arena. Having the initiation of LLM processing be manual on the part of the DFSG team members, instead (even if potentially one which could be as simple as a list of packages with checkboxes and a "check all" button, then a "queue all checked for processing" button) - or even providing an interface option (whether per-upload or as a preference option, or whatever else) for the uploader to say "let a LLM process this automatically" or "do not let a LLM process this without a further decision being made" - seems to me as if it would reintroduce the layer of agency and responsibility, between the uploader and any LLM processing that may occur, that seems to be missing under what I understand to be the current situation. It would, of course, also increase the workload of the DFSG team again... but on the one hand I hope that something like the proposed interface for initiating processing could make that increase relatively minimal, and on the other hand that may be the least problematic tradeoff against the negative of people being deterred from uploading to NEW when there would otherwise be good reason for doing so. -- The Wanderer may well regret sending this, but hope springs eternal The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
