<div dir="ltr">Hi all,<div><br></div><div>I must say I'm not very enthusiastic about adding such a flag. If there is a malicious intention, this flag will obviously not be enabled. If we're talking about code quality and risks, I would consider that having AI in the loop is not a sign of lower quality or higher risks to me.<br>Then, if this flag has a default value, the level of confidence will be very low.</div><div>So I personally don't see an added value for this.</div><div><br></div><div>I personally would rather try to use AI to actually do the reviews of the plugins, remove the human in the loop (at least at the first round), where a human is actually not good at. But I think this is already under discussion, and probably not the original topic, but somehow related.</div><div><br></div><div>Cheers,</div><div>Denis</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Le lun. 9 févr. 2026 à 18:48, Régis Haubourg via QGIS-Developer <<a href="mailto:qgis-developer@lists.osgeo.org">qgis-developer@lists.osgeo.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<div>Hi, I agree AI is making the plugin's
ecosystem being boosted, with all the good and bad sides you
mentioned. </div>
<div><br>
</div>
<div>I like the idea of a field in
metadata.txt for a spontaneous disclosure.</div>
<div>From what we see on PR's or security
disclosures is that some AI users are reluctant to reveal they
worked with AI. And probably, many dev's will use a bit of AI
autocompletion most of the time. </div>
<div>It takes some rounds of discussions to
spot that they don't fully understand the code they produced,
which is the famous AI slop. </div>
<div>So in my opinion, we should be able to
use a `ai_possible_derivative` flag as moderators, from the
plugin's catalog. Maybe it is time to set up a full community
discussion and voting system, just as internet browsers do for
plugins. <br>
One should be able to signal a malicious, or badly coded plugin
triggering crashes. And moderators should be able to ban / alert /
flag plugins beyond the volontary metadata.txt tooling. And maybe
we would have to add automated scanners for security security,
code smells, and now AI smells.. </div>
<div><br>
Maybe Lova could tell us about ho this is doable, and if we have
the resources to do this this year. </div>
<div><br>
</div>
<div>Cheers</div>
<div>Régis</div>
<div><br>
</div>
<div><br>
</div>
<div>On 2/9/26 14:36, Admire Nyakudya via
QGIS-Developer wrote:<br>
</div>
<blockquote type="cite">
<p>Dear All</p>
<p>The rapid proliferation of AI tools has led to a noticeable
increase in QGIS plugins being created and uploaded to the
registry. </p>
<p>The bonus points for these new plugin are:</p>
<ul>
<li>functionality gaps are being filled faster</li>
<li>workflows are consolidated</li>
<li>innovation is happening at pace. </li>
</ul>
<p><br>
However, it also introduces new challenges for the QGIS plugin
ecosystem, particularly around trust, review, and governance.<br>
<br>
While responsibility ultimately lies with end users to decide
which plugins they trust, the growing use of AI-assisted or
AI-generated code raises additional concerns beyond those
already discussed in recent QGIS pull requests/code base related
to AI usage. </p>
<p>The plugin approval process relies heavily on volunteer effort
and with the many plugins being uploaded we have to rely heavily
on authors to submit high-quality, secure, and maintainable
code. <br>
<br>
The plugin review process is not focused on code review but does
so in limited circumstances. End users rely on author
reputation, plugin ratings— as indicators to trust the plugin
quality and usefulness.<br>
<br>
To improve transparency and support informed decision-making, it
may be worth introducing an optional metadata flag in <b>metadata.txt</b>,
for example:<br>
<br>
<b>ai_derivative = yes</b><br>
<br>
All existing plugins could default to no, with the flag applied
to new or updated plugins going forward. This would not act as a
quality judgement, but rather as a disclosure mechanism,
allowing users to filter plugins and assess trust based on their
own criteria, alongside authorship and plugin rating.</p>
<p>Regards</p>
<p>Admire (Active plugin reviewer)<br>
<br>
</p>
<div>-- <br>
<div>
<p>GIS Engineer</p>
<p>Location: <a href="https://w3w.co/amused.thunder.wins" target="_blank">Geolocate me here</a></p>
<p>Phone: <a href="tel:+27639664031" target="_blank">+27639664031</a></p>
<p>Email: <a href="mailto:addloe@gmail.com" target="_blank">addloe@gmail.com</a></p>
<p>Social Media:</p>
<ul>
<li><a href="https://www.linkedin.com/in/mazano-gis-geek" target="_blank">LinkedIn</a></li>
<li><a href="https://github.com/NyakudyaA" target="_blank">GitHub</a></li>
</ul>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
QGIS-Developer mailing list
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a>
</pre>
</blockquote>
<p><br>
</p>
</div>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div>