[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.

[Andersson007]

As there are no more opinions, I suggest the following voting options based on the comments above (if you have something to add, please say until Monday 12.13.2021, the voting will be open on Monday):

Question 1:
a) Create repo ansible-collections/changes_impacting_maintainers, close issue 45
b) Create repo ansible-collections/changes_impacting_maintainers, do NOT close issue 45 (when a new issue is created in the repo, put a comment in issue 45 with a reference to the issue in the repo)
c) Do NOT create the repository instead of issue 45 (i.e. continue to use only issue 45 as now, the proposal isn't worthwhile)

Question 2 (provided that you vote on Question 1 with a or b):
a) Use issue per change announced
b) Things are stored in the repo: file per announcement; discussions can happen in Pull Requests adding those files
c) Use discussion per announcement

[sivel]

Q1) +1 for a
Q2) +1 for a, -1000 for b, I've never actually used discussions so I don't really have an opinion about discussions

[sshnaidm]

(we can create an actual poll: evenchange4/gh-polls-bot#26 (comment))

1. a or b
2. a or c, preference to c

[tadeboro]

q1 - a (to have a single source of truth)
q2 - a (because it is the simplest of the available options)

I would go with q2c q2b (for some reason I swapped the b and c in my original answer) if notifications had more content, but as of right now, going that way would only complicate things for no real benefit.

[briantist]

Q1) a
Q2) a (maybe c, but I haven't used discussions... so I can't really say)

to elaborate on Q2, I want to:

1. subscribe to the new repo, so I get notified about new issues
2. be able to then unsubscribe from individual issues that don't concern me (I want to get notifications on issues I am interested in, and no notifications on ones I'm not)

I think issue per announcement works for the above. If discussion per announcement does too, then I'm probably fine with it; I just don't really know/understand how it would differ from issues.

[felixfontein]

Ok, so I guess voting already started. I understood @Andersson007 that we'd begin on Monday, and have time until then to adjust the questions we want to vote on. But I guess that's too late now :-)

Q1: a (I could also live with b, but if we do that we should only paste general things, not "CI in these repos have to be adjusted" checklists which are only of interest to a very small subset of maintainers, namely the ones of these collections :) )
Q2: a (I could also live with c, but I find issues easier to handle, and tooling for them is a lot more mature)

[Andersson007]

Ok, so I guess voting already started. I understood @Andersson007 that we'd begin on Monday, and have time until then to adjust the questions we want to vote on. But I guess that's too late now :-)

No problem, folks seem to be satisfied with the options as they are now:)

Q1: a
Q2: a

[Andersson007]

Async voting is open (since Friday)! Could you please vote ASAP @jillr @cyberpear @gundalow @acozine @ssbarnea @cidrblock @thaumos

[jillr]

I'm +0 to any proposal. I was the sole person that actually liked the current setup, but I won't block what other folks prefer since I don't have another proposal to offer. :)

[gundalow]

I'm currently +0 on this.

Whatever's decided I think it would be good to use the recent changes in #45 to show what it would look like under that new process.

[Andersson007]

@cidrblock @ssbarnea @cyberpear and @thaumos the async voting is going on and we need your voices on #51 (comment)

[thaumos]

+0

[acozine]

I like @jillr's newsfeed idea. GitHub is optimized for tracking software development, and this feels like a different kind of problem. We may need a tool that's optimized for distributing announcements/news. It sounds like the problem we're trying to solve is "as a contributor/maintainer, it's hard for me to find information". Can we explore other tools that might serve this need better than GitHub? Do we know more about the problem? What kinds of information do people look for (and fail to find) most often? the most recent changes? historic information? topics, searchable by keywords? most relevant? What kinds of problems had this caused? At some point the perfect becomes the enemy of the good, but the underlying problem here may be that we're using a hammer when we need a socket wrench.

[sivel]

Can we explore other tools that might serve this need better than GitHub?

On the flip side, if you make the barrier to entry pretty much any higher than it is now, you are less likely to have people actually make announcements.

[briantist]

To answer @acozine 's questions, and to @jillr 's point, I don't think the current system is failing to meet needs for the most part. I am fine with it mostly, and although I may have missed it, I don't see maintainers saying that they missed announcements or information.

For me, the one big negative of the single issue is all down to GitHub's UI being terrible when the number of replies gets large; they hide replies and there's no easy way to show them all (click "show more" over and over and over). Even when you link to a single comment via a permanent link, it doesn't properly expand it, so linking to those individual comments from elsewhere is problematic.

The next biggest (and much smaller) issue, is that asking questions about or discussing an individual announcement can get messy, and it adds noise in between the announcements.

Other than these, I think the current system is fine for its primary purpose: letting maintainers know about changes impacting them.

I think a dedicated repo with single issues solves both the above issues, while still meeting the primary purpose (and allows for a few more little advantages).

I really do not want to look at solutions outside of GitHub; I don't want RSS feeds, I don't want another separate mailing list, I want to be able take advantage of GitHub linking.

[Andersson007]

+100 to what @briantist said

[Andersson007]

It has been implemented, I'll close it. Thanks everyone!