[Vote ended on 2022-01-11] Repository instead of Changes impacting collection contributors & maintainers Issue

[Andersson007]

Summary

The idea was originally said by @mattclay

We should replace "Changes Impacting collection contributors and maintainers" Issue 45 with a dedicated repository (for example, we could create ansible-collections/changes_impacting_maintainers).

Issue: Now it's a problem to find anything in the issue (even recent announcements) as it's hard to unfold 460 hidden items to find important information. Things get lost there quickly...

Solution:

• Using a repository instead.
• Announcements will be done as separate issues.

Benefits:

• Possibility to ask questions in issues, discuss things, add clarifications.
• Easy tracking maintainers who are subscribed / not subscribed (to remind them if we see that they don't consider the changes in their collections
• Easy linking related PRs / issues in collection repos (now this causes a need to unfold 460 hidden items in the single issue).

Questions that can be asked:

1. What about changes that aren't (only) about collections?

• Currently Issue 45 is in ansible-collections/overview.
• At least recently I can see things that relate to collections only. I believe we should keep the focus.
• If there's a need for Issue of broader scope than Changes Impacting, it would already exist.
• We have Bullhorn. We recommend maintainers to subscribe to it. As far as I noticed, important changes of different areas (and global ones) are announced via the newsletter.
• Bullhorn + the repo is a good combination for collection contributors and maintainers. For others, Bullhorn + corresponding repos.

Conclusion:
I suggest creating the repo ansible-collections/changes_impacting_maintainers that will keep focusing on collection contributors and maintainers and close Issue 45.

[felixfontein]

👍 for this!

[tadeboro]

I am not sure about the "one issue per change" thing here. The main reason is that I do not see good criteria for closing the issues. And without that, we will end up with a large "backlog" of topics that are not much easier to navigate than comments in a single issue.

Maybe having things stored in a repo would be a better choice? For example, having a separate document for each new announcement, possibly grouped by the Ansible version. We would introduce new content through PRs so that the interested public can still subscribe to something instead of just scanning the content at regular intervals.

I am not sure if this is a good idea, but I am throwing it out there just in case.

[sshnaidm]

I like having updates on mail like it's now. I don't think anybody will go here to look for new changes. Also Bullhorn is not a replacement since it comes out once a month only. I'm fine with any way that will send me updates about every change.
Tracking of a specific issue is not really required.
Maybe we can use Discussions?

[Andersson007]

@tadeboro how about labeling (e.g. default_test_container, new branch, matrix update required, etc.)?
From my perspective long backlog of open issues is not a big issue - grouping by labels should help filter out things that you're not interested in.

[sivel]

+1 for new repo. I could also be convinced to use discussions

[felixfontein]

I think the main difference between issues and discussions is that IMO the handling of issues in the GH UI is more mature. Also discussions cannot really be closed, only locked and/or deleted. I think issues would work better.

[jillr]

My preference would be a news/rss feed of announcements, I feel like having issues per topic/announcement will encourage an increase in those tickets being treated as discussions/proposals rather than static announcements and thus become noisy. But I won't block on it since I'm not offering to build a system for publishing announcements. :) I'm +0/abstain from any vote.

[felixfontein]

Also as this has been mentioned a lot: I don't think that this will result in a lot more discussions than we had before in that issue. So the volume of mails/notifications should be similar as before. (Of course we only find out if we try :) )

[briantist]

I like that I am subscribed to an issue and get notified on new stuff. I have no issue (😁) with it except the GitHub hidden comments UI disaster.

If it's a new repo, I can do the same, subscribe to it and get notified on new issues and/or PRs.

The files thing sounds complicated/unnecessary to me, but open to see how it goes.

In any case, it would be nice to be able to discuss individual ones in more detail (when needed) without feeling like we're clogging up the single issue (and folks can individually unsubscribe to not get notified about single-issue discussion that's not relevant).

[felixfontein]

We could also have a hybrid approach: have issues (or discussions) in a repository as the main content, and automatically generate a stream (RSS or moderated issue) out of this from the first posts in every issue in that repo. The main downside would be that the auto-generated stream would not get updates/clarifications that are added later to the issues in the repo.

[Andersson007]

• issues would work better for me than discussions because I can link related PRs to the issues (as many folks including me do now in issue 45) and then track the progress looking at references to them and their state ("open", "closed", "merged" - heh, it feels like a kind of dashboard:)) in the issue which is especially convenient when fixing things across many collections.
• also issues describing things like Changes impacting Collection Contributors and maintainers ansible-collections/overview#45 (comment) that contain checklists can be eventually closed and forgotten after all checkboxes are marked as solved.