About the current process to suggest trivial/cleanup changes

[Jaime Hablutzel]

What’s the simplest procedure available now for suggesting trivial or cleanup changes, to be processed later through a cleanup Ballot?

Is there anything in place that lets anyone propose changes via pull requests, have someone triage and label them (e.g., as “clean-up”), and then have them properly reviewed and (possibly) adopted under the regular cleanup Ballot process?

I think providing a lightweight process for suggesting changes—without requiring too much time (as in the standard PR workflow used in open-source projects)—would lead to faster improvements in document quality. I’ve lost count of the times that, while reading the documents, I’ve noticed minor, trivial things to improve; not having a quick way to report them has simply discouraged me from reporting in most cases.

I’ll be grateful for your opinions. The last thing I got on this was a Ryan Sleevi’s comment several years ago: https://github.com/cabforum/servercert/pull/322#issuecomment-938040108. That PR, labeled as “clean-up,” is still open, as are most of my other (almost) trivial PRs: https://github.com/cabforum/servercert/pulls/hablutzel1 (some of them may be outdated, though).

[Adriano Santoni]

I agree.

Adriano

Il 10/02/2026 20:39, 'Jaime Hablutzel' via Server Certificate WG (CA/B Forum) ha scritto:

[NOTICE: Pay attention - external email - Sender is servercert-wg+bncBCJ7NW5...@groups.cabforum.org ] 





What’s the simplest procedure available now for suggesting trivial or cleanup changes, to be processed later through a cleanup Ballot?

Is there anything in place that lets anyone propose changes via pull requests, have someone triage and label them (e.g., as “clean-up”), and then have them properly reviewed and (possibly) adopted under the regular cleanup Ballot process?

I think providing a lightweight process for suggesting changes—without requiring too much time (as in the standard PR workflow used in open-source projects)—would lead to faster improvements in document quality. I’ve lost count of the times that, while reading the documents, I’ve noticed minor, trivial things to improve; not having a quick way to report them has simply discouraged me from reporting in most cases.

I’ll be grateful for your opinions. The last thing I got on this was a Ryan Sleevi’s comment several years ago: https://github.com/cabforum/servercert/pull/322#issuecomment-938040108. That PR, labeled as “clean-up,” is still open, as are most of my other (almost) trivial PRs: https://github.com/cabforum/servercert/pulls/hablutzel1 (some of them may be outdated, though).

[Dimitris Zacharopoulos (HARICA)]

Hello Jaime,

The common practice is to create a GitHub issue, label it as clean-up, and ideally include proposed language. You might even start a new PR labeled "Cleanup 2026" :)

I'm not sure if the best course of action at this point is to add your proposed changes to the current SC095 ballot. I'd rather you open one or more issues that can be tackled in future clean-up ballots.

Hope that works.

Best regards,
Dimitris.

[Jaime Hablutzel]

Thanks Dimitris. 

So one currently valid workflow could be to create a PR (which makes it easier to suggest/discuss changes) and then create an Issue (labeled as 'clean-up') to simply link the PR?

Has it been considered to directly accept PRs instead of having to create (mostly redundant) Issues? GitHub uses the same number sequence for Issues and PRs and it even allows to list both PR and Issues at the same time, e.g. https://github.com/cabforum/servercert/issues?q=state%3Aopen

On 11 Feb 2026, at 4:45 AM, 'Dimitris Zacharopoulos (HARICA)' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:

 Hello Jaime,

--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/425632b6-5025-4d07-a3cf-15766f21570c%40harica.gr.

[Dimitris Zacharopoulos]

I think it's best to use issues to be discussed. A PR is a step before the ballot.

What do others think?

Thanks,

DZ.

Feb 11, 2026 16:09:44 'Jaime Hablutzel' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>:

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/DB263637-1232-478C-A035-3FC90F3613CA%40wisekey.com.

[Aaron Gable]

I think it is very important to have the GitHub Issue, because it has much better staying power. On the assumption that we only do a cleanup ballot once a year, a PR may become very out-of-date and require someone other than the original author to do a messy merge to make it cleanly apply on top of the most recent BRs. If they don't have the context of an issue plainly laying out what the problem is, they may do that merge incorrectly. Having the issue provides a place for lots of context and discussion, which are invaluable when months may pass before the fix is actually merged.

Having a PR as well is fantastic. Definitely makes the job easier. But I don't think it's enough on its own.

Aaron

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/aa7717b8-a4fb-4e6a-93c9-4a7be795deac%40harica.gr.

[Jaime Hablutzel]

On Feb 12, 2026, at 7:41 PM, 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:

I think it is very important to have the GitHub Issue, because it has much better staying power. On the assumption that we only do a cleanup ballot once a year, a PR may become very out-of-date and require someone other than the original author to do a messy merge to make it cleanly apply on top of the most recent BRs. If they don't have the context of an issue plainly laying out what the problem is, they may do that merge incorrectly. Having the issue provides a place for lots of context and discussion, which are invaluable when months may pass before the fix is actually merged.

Hi Aaron. I totally agree on the previous, but GitHub pull requests provide (to the best of my knowledge) the same that Issues provide and more on top of that. Even if a PR branch becomes outdated, the PR’s commits and discussions (general or line level) could provide the context necessary to put the changes back on top of the current `main`.

Here are some extra advantages for PRs I can think of.

Even when cleanup ballots will eventually use a different consolidating PR, having separate small PRs for each cleanup-like change provides the Git/GitHub benefits like history tracking and discussion directly linked to specific lines.

Having a single location to propose and discuss changes provides for easier analysis and explanation of changes in the future. Having separate places like one Issue and potentially multiple PRs (as I’ve seen before multiple times), makes it considerably harder to locate the rationale for specific changes. This is something I stumble upon from time to time (and maybe I’m not the only one) when I’m looking for context or rationale for a small piece of text and from my experience with CABF repositories, the process usually involves git blaming, locating and reading multiple PRs and Issues, mailing list links (sometimes found in commit messages), etc. And many times even this doesn't suffice to locate rationale, so I try searching in the mailing list, previous minutes, F2F presentations, etc. It is a very time consuming process without guaranteed success.

In summary, promoting the centralization of changes proposal and discussion could provide for (very) easier future analysis or maybe I’m just doing something very wrong when looking into past changes.

Regards.