Please add the modified field requirement as a rule in the page rather than a note at the bottom.

@mohanboddu That feels like an implementation detail, not a policy. Just a note to remember we need to fill it in seems good enough for now.

Thinking about it, ideally, it's probably something that a human shouldn't really be doing. @sgallagh what if we added a new command to fedpkg that would manage defaults in a similar way to how it's going to manage EOLs? https://pagure.io/modularity/issue/129 It could do policy checks, calculate this modified field, and maybe send a PR or at least print the result out?

@asamalik I see your point, but its definitely an important info for the maintainers to look at. Probably a Note or something to highlight it rather than just an extension to a sentence.

So, I've been thinking about this and I disagree that this belongs in the rules section. That section describes "when" to set module defaults, but not the "how". I think @asamalik is right that packagers should not, in fact, be responsible for this. The fact that we can take pull-requests is probably something we should discourage and instead either build a proper tool that creates those PRs (as suggested) or recommend that packagers just open a ticket to have one of the maintainers generate the document correctly.

I'm tempted to disallow PRs against the repo at all and require a ticket. Pagure allows us to turn PRs off. Then we could have fedpkg just behave like it does for fedpkg request-branch and just file tickets automatically (possibly auto-generating the modulemd if we want to go that route).

Yeah, I think I agree with @sgallagh about disabling the PRs. There is nothing creative to be done, and if people make a typo/mistake in the PR it's actually more work for everyone — a release engineer would need to to ask for a fix or to close the PR and just do it anyway...