adding a comment to issues when placing them on the next agenda "This issue will be discussed at the next meeting on XXXX", this will allow cc'ed change owners to know when they should be available to help answer questions or proposed changes.

This is useful and I think we should do it, yes

For changes, make a edit to the wiki page, noting the issue will be discussed in the next meeting to allow for all watchers of that page to know it's going to be discussed.

This sounds rather complex and I don't think that many people would watch it other than change owners.

It's been suggested that we should update our meeting process by:

• adding a comment to issues when placing them on the next agenda "This issue will be discussed at the next meeting on XXXX", this will allow cc'ed change owners to know when they should be available to help answer questions or proposed changes.

Does mentioning a user in the issue subscribe them to future updates? AFAIK, it doesn't.

• For changes, make a edit to the wiki page, noting the issue will be discussed in the next meeting to allow for all watchers of that page to know it's going to be discussed.

I agree with Miro that this is probably more involved than the actual utility justifies.

Counter proposals?

Not a counter proposal, but I think including the relevant people on the agenda announcement email's to: field would be sufficient (perhaps with the additional step of noting it in the issue comments).

It's been suggested that we should update our meeting process by:

• adding a comment to issues when placing them on the next agenda "This issue will be discussed at the next meeting on XXXX", this will allow cc'ed change owners to know when they should be available to help answer questions or proposed changes.

Does mentioning a user in the issue subscribe them to future updates? AFAIK, it doesn't.

Correct. It only sends them that one comment, they would have to go to the issue and subscribe to it to keep getting updates.

• For changes, make a edit to the wiki page, noting the issue will be discussed in the next meeting to allow for all watchers of that page to know it's going to be discussed.

I agree with Miro that this is probably more involved than the actual utility justifies.

Counter proposals?

Not a counter proposal, but I think including the relevant people on the agenda announcement email's to: field would be sufficient (perhaps with the additional step of noting it in the issue comments).

It's hard to see who the relevant people would be from the issue, but I guess they are listed on the change page...

It's hard to see who the relevant people would be from the issue, but I guess they are listed on the change page...

They're also listed in the "Owners" in the initial comment in each issue. Of course, there may be additional people who are interested, but at least that gives you the list of change owners at a glance. I think anything we come up with is going to be okayish at best without a significant investment in tooling.

• adding a comment to issues when placing them on the next agenda "This issue will be discussed at the next meeting on XXXX", this will allow cc'ed change owners to know when they should be available to help answer questions or proposed changes.

This sounds like a good idea to me. We should also update the guidelines
so that they encourage change proposal owners to also subscribe to the
issue.

• For changes, make a edit to the wiki page, noting the issue will be discussed in the next meeting to allow for all watchers of that page to know it's going to be discussed.

Not sure if this is worth the effort.

Proposal:

• Update the FESCo meeting process documentation to add adding a comment like "This issue will be discussed at the next meeting on XXXX" to the pre-meeting todo-list for tickets that are tagged with "meeting", EDIT, and to @-mention any change owners or other stakeholders in that comment

• Update Change process documentation (where?) to encourage Change owners to subscribe to FESCo tickets once they are created by the change wrangler

These should both be very simple and achievable without investment into automation. What do you think?

+1 to @decathorpe's proposal.

+1 from my side as well.

+1

This ticket will be discussed during today's meeting: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/P5KOID677ZHCIW4ULTJJIE3OUWZ6IJ4L/

This was discussed during today's meeting.

• 2646 update meeting process (decathorpe, 19:51:17)
• LINK:
  https://docs.fedoraproject.org/en-US/program_management/changes_policy/
  (mhroncok, 19:53:56)
• LINK: https://pagure.io/fedora-pgm/pgm_docs/issue/6 (bcotton,
  19:57:15)
• AGREED: APPROVED Updated Meeting Process (+5, 0, -0) (decathorpe,
  20:00:40)

Additionally, we found that assigning the ticket to (one of) the Change Owner(s) is a simple solution to make sure they're subscribed.

https://fedoraproject.org/w/index.php?title=FESCo_meeting_process&type=revision&diff=633086&oldid=617596

https://pagure.io/fedora-pgm/pgm_docs/pull-request/16

The PR for pgm_docs has been merged.