[Vote ended on 2024-05-13] Steering Committee: update collection inclusion procedure

PR to discuss and vote on

Issues we need to solve

  • There’s an influx of new inclusion requests
  • I review them but i spend more time and energy to ping the committee to conduct the second review
  • This is not good and frustrating for the collection maintainers: they do work to make their content compliant
  • In short, the two reviews and two SC approvals scheme doesn’t work and is not gonna work if there no other committed volunteer from SC who will review stuff on a regular basis (if someone wants, please raise your hand)

Solution

  • Change the process so that if another person from SC wants to conduct the second review they can go ahead otherwise one review and approval is imo enough.
  • I expect someone raises concerns about possible quality deterioration but the two reviews scheme just doesn’t work - I regularly published and publish calls for help but there’s no interest. We should trust each other, really. If someone has doubts and wants to re-check that, say, a collection has CI running regularly, they can do it.
  • We should not make people wait or we should stop including new stuff
1 Like

Sorry, I just don’t find the time to work on those inclusion requests :-/

First things first, I think one review is mostly sufficient. (Yes, I trust you!). But I still have a bad feeling about including the collection in question automatically. Maybe make it a requirement to announce this somewhere (forum topic and / or community meeting and / or Bullhorn) and include if nobody objects in $WEEKS? :thinking:

Apart from this:

  1. Can we automate some checks? published on Ansible Galaxy with version 1.0.0 or later, have a public git repository, releases of the collection are tagged in this repository, meta/runtime.yml defines the minimal version of Ansible which the collection works with and maybe some other things could be tested by a script. This would make reviewing easier.
  2. Are there any requirements we could possibly drop? At the moment, I don’t see one but maybe there are. Could also make things easier.
1 Like

@mariolenz i think this is already that requirement or did i misunderstand the suggestion?

I think this is not the root reason though. I think it’s just not interesting to people or they already have too much on their plates.
I wouldn’t say it takes a lot to check those items even manually (10 minutes max for all). But yes any automation is much appreciated.

I think the most time consuming things are those important ones like adherence to doc and code standards. We could anyway re-evaluate other items and it’s good to have fewer items if reasonable. Though in the context of the topic, i don’t think it will solve the issue.

With the suggested change, people interested in scrutinizing some collection can always start another review.

Sorry, I’ve overlooked the link to the PR and just read you text. Yes, you’re right: It’s already part of the PR.

I agree, it wouldn’t solve the issue. But since we’re discussing collection inclusion, I wanted to bring this up. Maybe it would make the reviews a little bit easier. But it’s a bit off-topic since the main proposal is to drop the (mandatory) second review.

@SteeringCommittee We’ve discussed this in today’s community meeting, but I think it would be great if we would discuss the proposal right here.

After all, that’s what these forum topics are for… aren’t they? :smirk:

1 Like

Hmm, this is a complicated (and recurring) topic :slight_smile: I personally don’t like the idea of not having a second review. I’m fine with having a reduced second review, where the ‘simple’ to check items are skipped (like: tests running? public git repo? etc.) and the review concentrates on the ‘important’ topics (like code quality, good plugin/module design and sticking to the guidelines for these, and quality of documentation).

We already opened up the group of reviewers by allowing non-SC members to do one of the two reviews in the past. That apparently didn’t result in a larger number of reviews.

(I’m also wondering more and more whether we want to have more restrictions on what to include in the Ansible package. But that’s another can of worms we’re regularly opening a bit, peeking in, and closing before too many of the worms can crawl out - this topic isn’t the best place to do this again :slight_smile: )

2 Likes

2 posts were split to a new topic: Future of the Ansible Community package

As this topic depends on the package future on (thanks @samccann for creating it), let’s wait until there’s more feedback in that one.
I’ve just suggested one solution, please take a look Future of the Ansible Community package - #21 by Andersson007. I think it promises some very exciting work :wink:

@felixfontein i like this idea, let’s try, updated the PR

The package future discussion might take long but we need to sort out the inclusion requests influx now. So folks please take a look. If no objections, I’ll start a vote.

Honestly, I’d support a memorandum on new collections until we can better define the scope of the package rather than weakening the review process.

1 Like

I’m OK with it but let’s move forward in the package future one, suggested questions for polls, please take a look

I see the discussion about the future promises to be long. Let’s proceed with a requirement update. Anything else to add/change in [Needs SC vote before merging] SC: update collection inclusion procedure by Andersson007 · Pull Request #1256 · ansible/ansible-documentation · GitHub ? @felixfontein you left a few comments there, answered, PTAL
I’d like to start a vote ASAP

I’m fine with voting on it.

The vote will end on May 14, @SteeringCommittee please vote ASAP

    • Yes
    • No
0 voters
0 voters

I won’t summarize the vote results as they are seen very well (thanks to the forum feature), so it’s positive, merged, thanks everyone!