[Vote ended on 2022-01-11] Repository instead of Changes impacting collection contributors & maintainers Issue
Andersson007 opened this issue · 53 comments
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:
- 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.
👍 for this!
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.
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?
@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.
+1 for new repo. I could also be convinced to use discussions
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.
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.
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 :) )
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).
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.
- 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 ansible-collections/overview#45 (comment) that contain checklists can be eventually closed and forgotten after all checkboxes are marked as solved.
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
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
(we can create an actual poll: evenchange4/gh-polls-bot#26 (comment))
- a or b
- a or c, preference to c
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.
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:
- subscribe to the new repo, so I get notified about new issues
- 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.
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)
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
Async voting is open (since Friday)! Could you please vote ASAP @jillr @cyberpear @gundalow @acozine @ssbarnea @cidrblock @thaumos
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. :)
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.
@cidrblock @ssbarnea @cyberpear and @thaumos the async voting is going on and we need your voices on #51 (comment)
+0
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.
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.
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.
+100 to what @briantist said
+0 here. I do find myself wondering if in the future it might be better to have a repo of standards or statements that reflect the current state of things. It could be versioned, PRs made for changes, and a changelog generated for the things that have changed & might impact contributors.
Q1 b
Q2 b
One comment on storing things in files in the repo, and updating by PRs: I don't think there is much content in the announcements where this actually would make sense. The current state of what ansible-test tests should be documented in the ansible-core docs, and the current requirements on collection inclusion should be documented in the inclusion repo, for example. The only advantage of having such files would be (IMO) having a 'shadow changelog' of the ansible-core changelog (and some other things) that only covers maintainer-specific changes. I'm not sure it's worth the extra effort of creating something like that.
I'm fine with any solution, I just want a way to get a high signal/low noise stream of "hey, these things should be done within the next few days/weeks to stay on top of things" without random "what even is a collection?!" questions or comments about the changes interspersed.
Q1 a
Q2 a
Q1 a
Q2 a
Q1: a
Q2: a
Summary:
Q1a) sivel, sshnaidm (1/2), tadeboro, briantist, felixfontein, Andersson007, rockaut, LKaemmerling, saito-hideki - 4 committe, 5 community
Q1b) sshnaidm (1/2), (felixfontein), cyberpear - 2 committee, 1 community
Q2a) sivel, (sshnaidm), tadeboro, briantist, felixfontein, Andersson007, rockaut, LKaemmerling, saito-hideki - 4 committee, 5 community
Q2b) sivel, cyberpear, (tadeboro) - 2 committee, 1 community
Q2c) sshnaidm, (briantist), (felixfontein) - 2 committee, 1 community
where ( ) means that someone indicated less preference than for the other choice
+0 committee 4 members (gundalow, jillr, cidrblock, thaumos)
Q1: a (keep it simple, streamlined, single source of truth - link form the original issue to the new location)
Q2: c (issues should be close-able, and these announcements won't ever close)
FYI: tomorrow (Jan 11 2022) is the last day to vote:)
My take is that yet another repository will not sort out our problems by itself. Instead I would suggest using discussions, likely we a specific new topic and having one proposed change per thread, so you can easily track it. Once decision is made we can record it (pull request) inside the repo with link to discussion thread.
We could ensure that people are informed about changes using release process on github for the repository. Things like github-release-notes or release-drafter can automatically build release notes related to changes, all we need is to tag a new release every other week, when new changes were merged.
To give you an idea about how easy is to use release notes and to advertise/expose them to others, take a look at https://newreleases.io/pypi/ansible-lint -- which contains all release of ansible-lint. You can click on each of them and see what was changed and you can subscribe to them with email, slack and many other systems, including webhooks.
issues- good for todo things, should not be used for things that are debatable, those should go into discussions.discussions- good to gather feedback, ideas and to vote on which one should be taken. They are expected to be open for long period of time but can be close marked as resolved.release notes- mostly read only, good to record outcomes/decisions once made, can create a discussion thread to receive feedback. We don't want to update them once made.
Watching release notes is easy, but watching issues and discussions is tricky for technical reasons as you cannot watch a single label or topic. If you watch an entire repository you may get more noise than you want. I suspect many people just want to get notified about changes impacting them when these are made effective.
I don't think with the repository we'll get more noise than we currently have with the Changes Impacting issue where there's not much of it. Moreover maintainers should be informed about all the impacting changes that happen.
The vote has ended.
Summary:
Q1a) sivel, sshnaidm (1/2), tadeboro, briantist, felixfontein, Andersson007, rockaut, LKaemmerling, saito-hideki, acozine - 5 committe, 5 community
Q1b) sshnaidm (1/2), (felixfontein), cyberpear - 2 committee, 1 community
Q2a) sivel, (sshnaidm), tadeboro, briantist, felixfontein, Andersson007, rockaut, LKaemmerling, saito-hideki - 4 committee, 5 community
Q2b) cyberpear, (tadeboro) - 2 committee
Q2c) sshnaidm, (briantist), (felixfontein), acozine - 3 committee, 1 community
where ( ) means that someone indicated less preference than for the other choice
+0 committee 4 members (gundalow, jillr, cidrblock, thaumos)
Another way has been proposed by @ssbarnea but there was a time defined for suggesting vote options in the comment.
I also checked and can confirm @Andersson007's numbers.
Considering that ( ) entries have less preference than the other entries for the same person, I think it is clear when just considering committee votes, and when considering all votes, that Q1a and Q2a got a majority.
My counts are as following (SC marks members of the steering committee):
Q1a) Create repo ansible-collections/changes_impacting_maintainers, close issue 45: 5 committee, 5 community
- sivel
- sshnaidm
- tadeboro (SC)
- briantist (SC)
- felixfontein (SC)
- Andersson007 (SC)
- rockaut
- LKaemmerling
- saito-hideki
- acozine (SC)
Q1b) 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): 2 committee, 1 community
- sshnaidm
- felixfontein (SC)
- jamescassell (SC)
Q1c Do NOT create the repository instead of issue 45 (i.e. continue to use only issue 45 as now, the proposal isn't worthwhile): 0 committee, 0 community
Q2a Use issue per change announced: 4 committee, 5 community
- sivel
- sshnaidm
- tadeboro (SC)
- briantist (SC)
- felixfontein (SC)
- Andersson007 (SC)
- rockaut
- LKaemmerling
- saito-hideki
Q2b Things are stored in the repo: file per announcement; discussions can happen in Pull Requests adding those files: 2 committee, 0 community
- tadeboro (SC)
- jamescassell (SC)
Q2c Use discussion per announcement: 3 committee, 1 community
- sshnaidm
- briantist (SC)
- felixfontein (SC)
- acozine (SC)
We also have +0 from jillr (SC), gundalow (SC), thaumos (SC), and cidrblock (SC).
Based on the result, Q1a and Q2a is what we should implement.
Thank you all for helping us make a decision. Your opinion and effort are greatly appreciated.
Any ideas on how to name the repo?
Please suggest names. One that will be thumbed up more, will win:)
Deadline is 2022-01-16.
ansible-community/changes-impacting-collections
ansible-collections/changes-impacting-maintainers
ansible-collections/news-for-maintainers
ansible-collections/updates-for-maintainers
ansible-collections/changes-impacting-contributors ( thanks @felixfontein )
I am OK with any of the proposals. Still, I feel that the word maintainers better describes the target of notifications (not all collections are contributed to the community, yet maintainers of the proprietary collections that are only used in a company should also know about the changes). So my "vote" would go to the news-for-maintainers.
ansible-collection/news-for-maintainers has won. I've assigned the topic to myself. Will report back later.
FYI: the repository has been created.
Please do NOT post anything there before the final announcement is made!
I've created this Transition TODO issue containing a few basic points, so any ideas on how to make the move smooth are welcome!
It has been implemented, I'll close it. Thanks everyone!