Proposal: regular quarterly cadence for voting, starting September 30th

[bfabio]

Hey everyone!

I was thinking about our process for proposing and voting on changes to the standard and I still think it's a good process.

Ironically right now the thing that can stop it before it even begins is deciding when to actually start the vote. Everything might be ready, but without a set date, or if we have to wait until someone has the time to trigger it, the whole cycle stalls and loses momentum.

Up to now, the start has been a bit ad-hoc, usually happening when I could carve out a moment in my free time and when life didn't get in the way, which is trickier than it sounds. Now things might change allowing me to follow this more closely and we have the chance to make it predictable.

My suggestion is to fix specific dates for starting the voting process: begin on September 2025, and then repeat every four months: January, May, and so on. The current rules would still apply, with one week of voting.

The nice thing about having a fixed schedule is that everyone knows when the next vote is coming, with no guessing or delays. And if the formula works, we could even automate it, so that in the worst-case scenario the vote still starts without anyone having to push the button.

If we agree, the next vote could already by mid September, and from then on it becomes something we can all put in our calendars.

I'd love to hear what you think, whether these dates work for you, if you'd prefer the start or middle of the month, or if there's another rhythm that makes more sense.

[tomootes]

I think this is a good idea. A fixed schedule is easy to communicate to people. We can create a schedule and pin it to: https://github.com/publiccodeyml eg.

Maybe a scheduled community call would be nice as well?

[bfabio]

That's a nice idea, I think community calls can add value for dissemination and visibility. If there's interest, it just needs someone to take the lead in setting them up.

[tomootes]

@bfabio. I will think about whether i could lead the community calls. It doesn't need to take up a lot of time. We can schedule one every month, for example the first thursday of the month. The meeting may take an hour i think.

My consideration is that currently i'm not specifically being paid to contribute to the publiccode.yml standard. It's part of my work for developer.overheid.nl. Although i would enjoy doing the community management around here.

In my opinion the benefits of community calls are:

• Efficient for people who prefer realtime conversations over reading issues.
• Connecting/ onboarding contributers.
• Can be rewarding to meet people who are using the standard in their software.

[bfabio]

Let's try an set this schedule: September 30th, January 30th, May 30th.

📆 The next voting round will then start this September 30th with the usual procedure.

cc @publiccodeyml/steering-committee
@bgz @cknebel @ShimonShore @dptdgi @zorp

@tomootes