vastarchitecture.blogg.se - Mozilla bugzilla

> appreciate why they take the position they do. > I disagree with Corey and Dimitris, but I can understand and a glut of new incidents, module peers/owners on vacation), that helps ensure it's still prioritized quickly.

Put differently: The regular updates help ensure issues that CAs believe are closed are able to be promptly responded to and reviewed.

The proposal to N-I certainly prioritizes a Module Owner/Peer (Bugzilla will generate mails for them), but does nothing to affect the review and triage of incidents.

This has also been true of the incident reports and investigation: the incident reports go through initial triage and investigation, which means that if you have X hours in a day to review incident reports, the "newest updated" are given priority.

As CAs have shared in their own review of other CAs' incidents, they prioritize those incidents most recently reported, because they want to ensure they promptly review their systems.

That is, if a CA's judgement allows the CA to release themselves from an obligation, that sort of incentive greatly encourages CAs exercising poor/hurried judgement.

Their belief that the issue is fixed is by no means a guarantee that it is fixed.

Ultimately, the proposed path of not expecting updates is "trust the CA to make the good judgement", when the Incident Report itself is at least some signal and evidence that the CA has failed to exercise good judgement and good process.

Put differently: The moment the CA starts repeating responses also provides a useful signal, even for those not on the N-I, to thoroughly review.For example, if a CA or community member started observing the compliance incidents after the CA believed it was complete, they would receive no notification of the outstanding review. A CA stating that they believe their remediation is complete once, and setting N-I, actually provides no further signal. Historically, these bugs have involved a great deal of community discussion. N-I will only ping the entity who the N-I is requested for, and only show up on the dashboard of the entity that the N-I is requested for.It's a reliable, repeatable signal to the community that the CA believes their remediation is complete, in a way that is open for the whole community.I can think of some bugs that have demonstrated positive practices, and some quite negative, and happy to dig up examples of both if it's useful here. The ability to provide such updates is useful for continually demonstrating the CA has processes in place (e.g. To suggest this is a "solved problem" is to ignore that we're still filing issues on CAs for non-responsiveness. We've seen a number of CAs, stretching back for years, failing to implement these basic policies and checks.Thus, the argument that this is "content-free" is not really accurate, because it's indicative of functional processes at work. It's one of the few positive signals we have that a CA is actually capable of, and is actively, reviewing all of their CA incidents weekly.They receive some feedback that would reset the NI back to the CA. NI flag to Ben, the CA would not need to send weekly updates until Process would be for the CA to set the NI flag to Ben when itĬonsiders to have completed all remediation steps. Signal this properly to the Mozilla official. The situation where a CA thinks remediation is complete and does not

I understand the need to have clear semantics so we don't fall into I don't think this wasĮver intended when the "Keeping Us Informed" section was written but This doesn't seem to be meaningful at all. Report", until a Mozilla official reviews what has been submitted? The CA to continue providing weekly updates that say "nothing to Is pending review from a Mozilla official, does it make sense for If a CA claims to have completed all remediation steps, and the bug In a bug regarding the need for "weekly updates".ĬAs are required to provide timely updates on open incidents as I would like to ask for some guidance after reviewing a recent comment