I'm going to express my concern here.
Neil is a great guy and I like him.
But the "a little over a year" is my concern.
Looking at things, Neil certainly has been active over the past year. He is admin, fedora contact, and/or epel contact for 14 packages. And although 4 of those, he hasn't done a build for, that leaves 10 that he has.

So I looked at our requirements to join the EPEL Packagers SIG, and well ... umm ... let's just say it's lacking. Basically it says, "if we like you, you are in" ... really ... there is no criteria.

I'm not saying we shouldn't let Neil be in the epel-packagers-sig group. I'm saying ... we really need to push SOME criteria on it.
I don't want the SIG to let people in based on how popular they are.

No hard feelings, I totally understand and appreciate that concern. I had, more or less, similar questions when opening the ticket.

For my part, joining the SIG is a step towards showing my commitment to working on and furthering EPEL, and I do understand if my application is delayed pending discussions or outright rejected until such time as there are clear guidelines on membership.

I am removing this for "meeting" until this other issue is resolved.
https://pagure.io/epel/issue/268

We discussed this during the 2024-05-15 EPEL Steering Committee meeting (log). In the meeting we said that sponsors of the EPEL Packagers SIG would vote here in the ticket, but it seems we all forgot to record our vote.

The criteria we decided on for the SIG includes "experience with a wide variety of package types". As of today, Neil has done 11 EPEL updates all time. I would like to see more EPEL packaging activity before granting SIG membership. For now, I'm -1 on this request.

I do want to be clear Neil, I do fully support you increasing your involvement with EPEL and re-applying to the SIG at a future date. In the meeting I referenced above you seemed to welcome this approach. I look forward to working with you on more EPEL activities.

Carl has made a well-justified case, and I can't help but agree as well.

-1

I'm -1 too based on the meeting discussion. As Carl mentioned, more activity around EPEL packaging would be great. If you find yourself being blocked on something you're working on by virtue of not being in EPEL Packagers SIG, please do bring it up in Matrix and we can definitely help get things unstuck as needed in the meantime.

Speaking frankly: if the metric being used to measure experience is only EPEL packages, perhaps the documentation is not accurate still and needs to be updated further.

I'm happy to accept whatever decision is made here, but, I also cannot help but feel as though I'm sitting through another example of moving goalposts except, in this case, I am both the impetus for those goalposts being moved and also now rejected by the rules I myself helped put in place.

Speaking frankly: if the metric being used to measure experience is only EPEL packages, perhaps the documentation is not accurate still and needs to be updated further.

The purpose of the EPEL Packagers SIG is to do work on EPEL packages. Therefore work on EPEL packages is the most relevant experience for this SIG. Sponsors can factor in other experience as well, but there is no substitute for direct work on EPEL packages.

I'm happy to accept whatever decision is made here, but, I also cannot help but feel as though I'm sitting through another example of moving goalposts except, in this case, I am both the impetus for those goalposts being moved and also now rejected by the rules I myself helped put in place.

I'm sorry you feel that way Neil. As the SIG gains permissions to more and more packages, it is reasonable to periodically review the criteria for new members and verify the current members still need that level of access. As far as you've stated, you're not blocked on any of your current EPEL work, so you should be in good shape to continue your contributions to EPEL and build more direct experience.

Back to the task at hand, here is the current voting policy.

You must get at least 1 positive votes from SIG Sponsor with no negative votes, over a one week review period, to be approved.

The voting period has been open for four weeks. The current vote tally is 0,0,-3. As this doesn't meet the criteria to be approved, it is rejected at this time.

I'm sorry you feel that way Neil. As the SIG gains permissions to more and more packages, it is reasonable to periodically review the criteria for new members and verify the current members still need that level of access. As far as you've stated, you're not blocked on any of your current EPEL work, so you should be in good shape to continue your contributions to EPEL and build more direct experience.

Bluntly: I don't "feel" this way--it is the truth of the matter.

I applied to join the sig, and my application caused the criteria to be changed. I helped approve and review the criteria. The goalposts were moved.

Perhaps it is vain of me to think this is about me, but, honestly, what else could one think, looking at this objectively? I'm not sure.

I may or may not apply at a later time. I'm not sure it would be worth my time given my past experiences, and the above.

Naught for nothing, but if I am not eligible for membership in the sig, I believe the test of the membership list should be revisited, if indeed the increasing scope of the sig is of concern. It's also probably worth noting that growing the base of packages the sig is responsible for without growing the sig membership is, well, problematic.