#52 [Onboarding Series] Quality Assurance
Closed: Insufficient data 4 years ago Opened 6 years ago by jflory7.

This ticket is a stub for working out the artwork, concept, and steps involved for awarding a Fedora badge for contributors who would like to officially join the Quality Assurance team.

Badge Ideas

Suggested by @a2batic and @sumantrom:

  1. Badges for filing bugs (Bug Reporter): Awarded to users for filing badges in Bugzilla; series is ordered by 1st Bug, 5th Bug, 10th Bug, 20th Bug, etc.
  2. Badges for release validation testing (manual): Awarded to QA members who successfully complete release validation tests as part of the QA process (would need to have people to award this badge manually)
  3. Getting sponsored to QA group: Badge awarded to past and future members in the FAS QA group

Hey Justin

Kanika(a2batic) and me(sumantrom) were interested in working on this one. Here are some the badges which we after brainstorming found good to have and for new comers to get the sense of recognition.

Badges for Filing Bugs (Bug Reporter) : A major part of QA process is filing bugs as new contributor is asked to file new bugs under "Fedora" . A new badge for filing bugs will be a great value addition for the new comers and also fedora users in making fedora less buggy overall.It can be awarded for people who file their

1st Bug
Atleast 5 Bugs
Atleast 10 Bugs
Atleast 20 Bugs
Atleast 35 Bugs
Atleast 55 Bugs
So on and so forth

Badges for Release validation testing : Release validation testing is a process which takes place before an official Fedora release. Before the Final (GA) release, we have Alpha and Beta pre-releases, and at each of these milestones, nightly builds (nightlies) and composes are released and tested to ensure that the release meets quality standards. Release validation testing is one way tester can help Fedora get better and a tester need to run through a list of test cases and give the results on the Test matrices of the wiki page. since there is no fed-mesg integration which can help us issue badges automatically but we can give badges by the number of release validation manually.

Getting sponsored to QA group : This can also be a badge , since release validation requires people to edit wikis its essential that the members must be CLA+1 , which is why we can have a badge for people being sponsored for qa group. As it stands , anyone who is active on the mailing list and IRC is good to get sponsored in qa group

We can also have badges for participation in test days in near future , I will update this ticket !

Hi @sumantrom and @a2batic! Big thanks to both of you for helping jump on this one. :smile:

I love all the ideas for the badges. I think all three should be fairly easy to put together. The QA group membership one can definitely be automated, and I think the Bugzilla one should be hypothetically possible now too.

I'm going to edit these ideas into the original issue to help highlight them.

One thing that would be extremely helpful to research is more about how the Bugzilla fedmsg hooks work, and how we could write a rule for them. I'm not too savvy with fedmsg or datagrepper queries, but you can see examples of what they look like here. Judging by the docs, it should be possible to get the bug creator's email ID, but we will be banking on them using the same email in Bugzilla as they use with FAS. Perhaps @skamath might have some ideas here too.

Discussed in 2016-09-13 meeting.

This ticket is beginning to roll along, and we'll probably put full focus on it once #84 is closed (it's very close!). For now, @a2batic has started filing the badge suggestion tickets on the Fedora Badges Trac. Find the relevant tickets here:

We will need rules defined for sponsorship into the QA group as well as one for the Bugzilla ticket.

Once the badge tickets move along, we will revisit this ticket!

Metadata Update from @bee2502:
- Issue priority set to: critical (next week) (was: normal (1-2 weeks))
- Issue tagged with: blocked

5 years ago

It was decided in CommOps meeting on 2017-09-13, that CommOps would work towards an integrated document to guide different teams on how-to create effective onboarding guidelines and provide them with examples.

More Info here -

Ticket for how-to document to guide different teams on creating and implementing effective onboarding guidelines is here -

Since, we are just waiting on artwork for this, the Onboarding steps for QA could serve as an example for other teams. I have dropped a message on design team tickets.

Metadata Update from @bee2502:
- Issue set to the milestone: None (was: Fedora 25)

4 years ago

Metadata Update from @jflory7:
- Issue priority set to: no deadline (was: critical (next week))
- Issue set to the milestone: Future releases

4 years ago

Metadata Update from @jflory7:
- Issue untagged with: blocked
- Issue set to the milestone: Fedora 28 (to May 2018) (was: Future releases)

4 years ago

Metadata Update from @jflory7:
- Issue close_status updated to: Insufficient data
- Issue status updated to: Closed (was: Open)

4 years ago

Ticket closed

In the CommOps FAD, we agreed to close the on-boarding series tickets since they have stalled out. Most of them are blocking on specific Fedora Badges (and there are tickets already filed). If we want to revisit a specific team, we should file a new ticket and start from a fresh slate.

I think it's worth noting a lot of awesome work was done on this series in our beginning two years – thanks everyone who has helped on the on-boarding work over the years.

Login to comment on this ticket.