Hello Guillem, On Thu 30 Jan 2020 at 01:16AM +01, Guillem Jover wrote: > Some of the words chosen to convey normative meaning are glue words > used to build pretty mundane sentences, so having them appear around > while they might not convey normative meaning seems rather confusing, > and is a mental overhead when reading or drafting new text. Probably > more for non-native speakers. Thank you, I hadn't thought of it in terms of increasing the effort required to draft new text, which holds even if we fix all existing instances. > For example in ch-scope.rst in the entry describing the *may* keyword > the following sentence uses also «may». :) The ch-archive.rst contains > several «may» instances that do not feel like the normative *may*, at > least the ones in the DFSG? > > Perhaps instead of the potentially ugly uppercased keywords, marking > them as *keyword* like in the definition of the terms would go a long > way? One issue with using uppercased words is that people might think the words have the same meaning as they do in RFCs, which they don't. Your idea of marking keywords in bold wouldn't have this problem, and maybe it would actually make it /easier/ to write patches because you can see more clearly which of your words mean what. Thinking more, I believe that the issue you're raising here is separate from what Russ is trying to achieve in this bug. The problem you're identifying here already exists in Policy, before Russ's change is applied. So maybe we should discuss it separately. > BTW I guess the instances of «might» and «shall» need to be converted, > or added to the keyword list? What about «may not», or «can», «can't», > «cannot» and «could»? And I'm probably missing other words. :) I don't think we need to convert words that don't explicitly appear in the keywords list -- "may not" would inherit its meaning from "may" being a keyword, wouldn't it? -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature