+1

Yeah, I agree, but if we're to vote on something, we'd need a proposal of specific phrasing.

Ok, I'll prepare proposed changes to the wiki page and post them here, lacking a PR workflow for contents of the wiki :)

@decathorpe ping as a reminder :)

So, assuming we want to keep this documentation on the Wiki because of the magic macros that fill in the date of the next meeting on the email templates, I propose the following changes:

Pre-meeting

Under item 1): check for any open issues and pull requests:

• https://pagure.io/fesco/issues
• https://pagure.io/fesco/fesco-docs/issues
• https://pagure.io/fesco/fesco-docs/pull-requests

Under item 2): for each FESCo issue

additional item 2b) for each fesco-docs issue and pull request:

• process votes / check with stakeholders / etc.
• merge pull requests that have gathered enough positive votes, etc.
• add issues and pull requests to agenda that need discussion (negative votes and / or requests for changes?)

additional item 3b) check for closed fesco-docs issues and merged pull requests,
and add them to the schedule email

If we don't want to keep this page on the wiki, I can make a PR to fesco-docs to import the current version (without magic wiki macros) and then apply proposed changes on top.

Note that I would probably also file a fesco-docs PR anyway, to explicitly say that our voting rules also apply to fesco-docs issues and PRs.

I'd prefer to keep the page on the wiki. Those "magic macros" make it easier to get the dates right and to keep consistent formatting in our mails. (If each chair were to format each date manually, we'd end up with a panoply of formats.)

This will be discussed during today's FESCo meeting (starting 17:00 UTC in #meeting:fedoraproject.org).

@sgallagh raised the issue that the proposed wording implies that all changes to the docs need to be voted ("merge pull requests that have gathered enough positive votes"). I agree that this would be overkill. We get a lot pull requests that either didn't require voting in the past. This includes wording or formatting changes, and updates following a formal decision done previously. So it'd make sense to somehow avoid this implication.

We get a lot pull requests that either didn't require voting in the past.

Maybe they should have required it? Who decides where to draw the line between "this is a policy change" and "this is cleaning up formatting and clarifies a few things"?

Rather than make an arbitrary distinction here, I think it would be easier (and safer!) to just vote on all changes. It's not like adding a "+1" comment on a PR is an onerous task ...

I think it is onerous ;) We're having trouble voting responsively on tickets. Those docs tickets get an even lower response rate, and if we make this official, every typo fix will require at least a week of waiting.

What about this:

Patches that change the policies or introduce big changes to the text are subject to normal FESCo voting rules. Wording or formatting changes, and updates following a formal decision done previously, can be merged without a formal vote, after somebody other than the author approves the change.

?

This still suffers from the problem of "where to draw the line" between trivial changes and policy changes.

This still suffers from the problem of "where to draw the line" between trivial changes and policy changes.

I still think the answer is "Assume good faith that no FESCo member will change policy intentionally on a doc update". It's not as if we can't go back and fix a mistake later.

It looks like the idea in general is uncontroversial, and just my choice of words could be interpreted differently. Native speakers are invited to make suggestions for a better wording.

Pre-meeting

Under item 1): check for any open issues and pull requests:

• https://pagure.io/fesco/issues
• https://pagure.io/fesco/fesco-docs/issues
• https://pagure.io/fesco/fesco-docs/pull-requests

Under item 2): for each FESCo issue

additional item 2b) for each fesco-docs issue and pull request:

• process votes / check with stakeholders / etc.
• merge pull requests that have gathered enough positive votes, etc.
• add issues and pull requests to agenda that need discussion (negative votes and / or requests for changes?)

additional item 3b) check for closed fesco-docs issues and merged pull requests,
and add them to the schedule email

I think we should just approve this text. We can figure out the detail of which doc pull requests need voting separately.

+1

Folks, everyone who hasn't voted, please do so.

@sgallagh, @salimma, @kevin, @dcantrell, @humaton, @ngompa

It's find, I suppose. +1

+1 sure.

OK, after two+ weeks since the last call for votes, we have 5 positive votes. I'll mark this as:
APPROVED (+5, 0, 0)

@decathorpe can you adjust the wiki?

Announced in the agenda.

@decathorpe status here?