Hi Greg, Greg Hogan <[email protected]> skribis:
>> I am somewhat reluctant to automated expiration because that could leave >> us in limbo if the measures chosen in the GCD expire and nobody picks up >> the work of consulting the community to determine what to do next. > > GCD 008 will update the project documentation, pull request templates, > etc. None of that expires. If after a year the community is satisfied > such that the sunset date passes unnoticed then we continue under the > GCD 008 policies. > >> It seems safer to me to come up with a GCD defining a new policy >> whenever we have input that calls for a change. It forces us to have a >> discussion on how to address these changes. > > The GCD process requires 100% consensus for every change. (Nitpick: it requires *building* consensus, which is not the same as achieving unanimity on someone’s proposal.) In its current form, I view GCD 008 as precautionary measures against the practical risks associated with unregulated use of genAI¹. In that spirit, automatic switchback to unregulated genAI use upon expiry seems undesirable. I’m well aware that the GCD process is difficult, as you can imagine. On the plus side, I think it’s likely going to be easier to build consensus on updated rules two years from now because we’ll have more insight. ¹ https://codeberg.org/guix/guix-consensus-documents/pulls/13#issuecomment-16470989 >> > And with the recent change under "contribution acceptance" in >> > bd04d0962a I would be happy to see included something similar to >> > "mechanical integration of upstream bug fixes, configuration >> > parameters, and minimal source adaptations required to achieve a >> > successful Guix build". >> >> I wouldn’t want the list of “Examples of non-creative changes” under >> “Contribution acceptance” to be too long because they are just that, >> examples. Do you see any ambiguity here? > > I find more examples to be less ambiguous than fewer examples. Based on the list you give, I propose extending the list of examples under “Contribution acceptance” as follows: Examples of non-creative changes include mechanical conversions of package metadata from other repositories similar to those made by `guix import`, mechanical changes similar to those made by `guix refresh` or `guix style`, changes that merely follow suggestions made by `guix lint`, integration of upstream patches, changes of a package’s `#:configure-flags`, and similar package definition adjustments that are arguably below the [threshold of originality](https://en.wikipedia.org/wiki/Threshold_of_originality). WDYT? > The document should be as clear as possible, otherwise the consensus > is of no value if everyone has their own understanding. There was > another similar, small change in eac798a510 that deleted > "translations" when translations are still included in "any other > artifact". How was this clarifying? Florian Pelz of the translation team suggesting removing this specific example due to the current situation of Weblate². You are right that translations are still included in “any other artifacts” though. Florian, thoughts? ² https://lists.gnu.org/archive/html/guix-devel/2026-06/msg00282.html > The change in bd04d0962a swapped the reference to "legally > significant" for a ban on all copyrightable contributions. This is a > significant change so late in the discussion period! It’s a change in wording; the meaning and intent have not changed. Previously that rule used the phrase “legally significant” but many (including you) pointed out that this was unclear, in particular with the definition that appears in the GNU Maintainers Guide, so we came up with this alternate wording³. (I am grateful to Nguyễn Gia Phong and Jason Conroy for their help here.) ³ Discussion on wording started at <https://codeberg.org/guix/guix-consensus-documents/pulls/13#issuecomment-18020621>. Thanks again for your feedback! Ludo’.
