Introducing the New QA Dashboard: Gain Insights into the Fedora QA Community

[Sudhir Dharanendraiah]

Dear Fedora Community,

The Fedora QA team is excited to announce the launch of our brand new QA
Dashboard for the Fedora QA community! This dashboard has been designed to
provide you with valuable insights into what is happening in the Fedora QA
space, helping us all work together more efficiently and effectively.

As an open-source community, our collective efforts have always been
focused on ensuring the quality and reliability of Fedora. The new QA
Dashboard is a significant step forward in enhancing our QA processes and
fostering collaboration among contributors.

Here are the key features and benefits of the QA Dashboard:

Current Development Schedule: The dashboard provides an overview of the
development schedule of the current release with important milestones for
you to plan and stay ahead of the curve.

Blockers and Freeze Exceptions: You can now view the current release
Blockers and Freeze Exceptions along with the breakup of Proposed and
Accepted.

Calendar of Events: Take a look at what is coming up in the next 7 days.
Meetings and Test Days to plan your schedule accordingly.

Meeting Minutes: Stay up-to-date with the latest decisions made during the
QA meeting. Meeting minutes will keep you informed, ensuring that you are
always aware of the current state of Fedora QA.

To access the new QA Dashboard, please visit https://qa.fedoraproject.org/

We encourage you to explore the QA Dashboard, take advantage of its
features, and provide feedback. Your input is invaluable in improving the
dashboard and making it even more beneficial to the entire Fedora QA
community. Tell us what you would like to see in the dashboard!

Thank you for your continued dedication to the Fedora QA community. Let's
make the most of this new dashboard and work together to ensure the highest
quality standards for Fedora.

If you have any questions, suggestions, or need assistance with the QA
Dashboard, please don't hesitate to reach out to us.

Regards,
-- 

S*UDHIR D*

SENIOR MANAGER, FEDORA QE,
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Sudhir Dharanendraiah]

- Original Message -
| From: "Adam Williamson" 
| To: "Development discussions related to Fedora" 

| Sent: Thursday, October 13, 2016 12:26:10 PM
| Subject: Re: PROPOSAL: Blocking the release is our only "big hammer" — let's 
add a softer one.
| 
| On Thu, 2016-10-13 at 14:40 +1000, Jeff Fearn wrote:
| > On 13/10/16 14:02, Adam Williamson wrote:
| > > On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote:
| > > > On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson
| > > >  wrote:
| > > > > On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote:
| > > > > > All of the extra app stuff could be avoided if we disallowed
| > > > > > reporters
| > > > > > (or random people) to change the Severity and Priority fields.
| > > > > 
| > > > > Mmm, I don't really think so. Presumably it would be maintainers who
| > > > > got to set those fields, right? But they are doing so in relation to
| > > > 
| > > > No, why would you presume that?
| > > 
| > > I dunno, just seemed logical. That's how they're intended to be used at
| > > present. Bug reporters aren't supposed to set them and don't have the
| > > privilege purely by rights of having an account
| > 
| > This is true for priority but not true for severity. Severity is the
| > external, i.e. reporters, weighting
| > of the bug and you do not need to be in editbugs to set it.
| 
| That's not the intent of the fields as I understand them. 'severity' is
| supposed to represent how bad the bug is, whereas 'priority' is
| supposed to represent how important it is to get it fixed compared to
| other bugs in the same component. They're obviously related, but not
| the same, and it's not "severity is the reporter's opinion, priority is
| the maintainers' opinion", no.
| 
| I think you might be right that we allow the bug reporter to set
| 'severity', though.

There is no direct relation between these fields.
Many projects interpret in different ways, but the most common way is,
'severity' is what user thinks of the issue, how much of an issue it is for him 
('user' is a QE engineer/consumer or a developer of other component). This is 
usually set to get the attention of the developer/owner of component over other 
bugs in same component. 
'priority' is what the developer/owner of the component (owner of the bug) 
thinks its severity is. It can also be a consensus from all stake holders.

It is not uncommon to see high severity bugs getting triaged first. It is also 
a good practice to keep priority and severity at comparable, if not same level 
once triaged (i.e., it would not logically seem correct to see high severity 
with low priority or vice-versa after triage).

Regards,
Sudhir

| --
| Adam Williamson
| Fedora QA Community Monkey
| IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
| http://www.happyassassin.net
| ___
| devel mailing list -- devel@lists.fedoraproject.org
| To unsubscribe send an email to devel-le...@lists.fedoraproject.org
|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org