#664 Updating QA group join process
Opened 2 years ago by sumantrom. Modified a month ago

As the new Auth system is in place, unlike past, the members who want to join the FAS group now have to added by one of the person. In the past, we have seen people requesting for the QA group and it's outdated now.
There are two ways we can go from here:

  1. we can have people who send intro emails to tell us their interest in joining the QA group and we can add them

  2. We ask contributors to file ticket with sponsor tag on our fedora-qa pagure repo and post which we can add them up.

I understand we are closing in a release and this is probably not the time to think about this one. Hence we can revisit this topic during our next QA meeting. However, if anyone has thoughts and a spare bit of time, please weigh in!


The point is (that has always been one of my doubt): the introduction email is sufficient (low friction to join the team), or the person should be already known and trusted by someone else around the community?

The point is (that has always been one of my doubt): the introduction email is sufficient (low friction to join the team), or the person should be already known and trusted by someone else around the community?

No, an introduction email is enough.

  1. We ask contributors to file ticket with sponsor tag

This is the better option IMO because it provides easy visibility of state. But it's worth pointing out that users can't modify the tags of an issue (tested in #665). I'm not sure if that's currently configurable in Pagure.

Correction: there is an "Open metadata access to all" setting in Pagure that would enable this, but might be too broad for what you want.

  1. We ask contributors to file ticket with sponsor tag

This is the better option IMO because it provides easy visibility of state. But it's worth pointing out that users can't modify the tags of an issue (tested in #665). I'm not sure if that's currently configurable in Pagure.

Correction: there is an "Open metadata access to all" setting in Pagure that would enable this, but might be too broad for what you want.

That's fine, we can tag up the issues. Or can have one issue which people can come and type in their FAS names. Creating fresh issues will create a lot of issues and make searching kinda hard. QA is group which sees spike in membership request, having one tracker issue will be efficient that way.

I will wait for folks like adamw and kamil and others to vote in before change is made

Or can have one issue which people can come and type in their FAS names. Creating fresh issues will create a lot of issues and make searching kinda hard.

That defeats the purpose of using an issue tracker, IMO. It takes away the easy visibility of which requests are pending and not.

I don't remember, are we sending ticket emails to test@ ATM? If so, this could cause some duplication with self-intro emails. We could change the instructions to just say to put the self-intro in the ticket, but then we wouldn't be sure people had joined the mailing list, I suppose?

I don't remember, are we sending ticket emails to test@ ATM?

Nope!

We could change the instructions to just say to put the self-intro in the ticket, but then we wouldn't be sure people had joined the mailing list, I suppose?

Could go with "put your self intro on the mailing list and then get the link from hyperkitty and include that in the ticket"? Or sponsors could just make sure the person has posted a self-intro on the mailing list before granting group membership.

What if we simply didn't tell people to apply to the qa group? The only reason I can think of is when some service requires cla+1. That's wiki, I believe, but release validation matrices are open to anonymous access, and for testdays we have a webapp, and so most QA contributors shouldn't need cla+1 anyway. Am I missing something? Are there additional use cases?

If somebody needs cla+1 and wants to be in the qa group, we can have a note on our wiki directing the person to file a ticket in this tracker. But those should be rare occasions, as opposed to having it listed as one of the joining steps.

If we want to continue asking everyone to apply to the qa group, or if there are good reasons why everyone needs it, I'd honestly rather create a separate project in our namespace. Otherwise I'm worried real tickets updates would get lost in an occasional flood of join requests. If it is a separate project, it can be followed just by one or two people who usually grant those requests (or it can be followed by everybody but at least it can be filtered).

@sumantrom are you still interested in changing things here?

Login to comment on this ticket.

Metadata