On Thu, Apr 7, 2016 at 2:50 AM, L. David Baron <dba...@dbaron.org> wrote:
> > > I don't think the idea that a bug belongs in the triage queue if it > is untriaged and without a needinfo? is the right process. I think, > instead, that there should be less emphasis on needinfo? to a > specific person, and more emphasis on grouping bugs into a small > number of categories of information that is needed, and allowing > people to triage those separate queues. > If we do decide to have groups of people responsible for moving a bug forward, we need to have some way of making sure that this happens. In order to drive a quality product and community engagement, we need to do the following things: * If next steps are necessary, that we make sure those next steps happen. * Make sure bug reporters and other people reading the bug know what the decision or next step is or who is responsible for that next step. I'm very wary of group responsibility in general. In cases where there is group responsibility, such as the process to move bugs from Untriaged into better components, we're taking the time to define the expected response time with an SLA and then have reporting and monitoring to make sure that we're keeping up and nothing is falling through the cracks.. We could try doing this for other categories of group responsibility, but the cost of that is building and maintaining the infrastructure, and likely increased complexity. More inline and below. > Understand description > Do the developers or triagers reading the bug understand > what the reporter is saying? > If the bug/description isn't clear enough, the next step for the triage lead to set a NEEDINFO back the bug reporter to clarify the description and/or steps to reproduce? > Agree it's a bug > Do the module owners or peers or other authority agree that > the problem is a bug? > If this decision can't be made by the triage lead for the component, it should be possible to set a NEEDINFO to the ower or peer who is best capable of making the decision. Do you disagree? That list of people is typically small and well-known to the component triage lead(s). > > Can reproduce > Can others reproduce the problem described? > This is indeed tricky, but also the stage where many bugs seem to break down because of diffuse responsibility or even plain lack of software testers. In some cases, we have staff who can be responsible for this: on the Firefox frontend, this is the softvision testing team. Some components have dedicated testers who can be directly NEEDINFOed, and in other cases this can be managed through the program manager, Rares. On the platform team, the test engineers have been embedded into the engineering teams. For teams that do have embedded test engineers, it should be possible to NEEDINFO that person. As a prototype/test, Mike Hoye has been recruiting people to serve as front-line community triage helpers and leads for various components. I believe that one of our biggest opportunities is to integrate these triage leads with the testing process, in which case we should be able to NEEDINFO those individuals. If none of these are true, what are the other ways where we can get the required testing? Do you have an alternate proposal for how this would work? I expect that one outcome of triage is that we will find teams that just don't have enough software testing support, and we will either need to build a community or hire to fill the gaps. > > Why it's important > What makes this problem important or urgent to fix? > Yes! If this isn't clear, who owns this? Either the module owner/peer, or a product manager, usually. Are there cases where we don't know? > > How to fix > What should be done to fix the problem? > I'm a little surprised that deciding *how* to fix a defect necessarily blocks making a decision about it's importance: if we've shipped a major regression, I believe we need to be willing to triage it into fix-now or fix-soon without necessarily knowing how exactly it will be fixed. Can we try this without group responsibilities and if we find categories of bugs where group responsibilities are *necessary* add the extra process to support those later? There are likely ways to solve this where we NEEDINFO a group alias in bugzilla and then provide a group triage view and monitoring. We're planning on this being the first step of large iterative improvement, and my goal is to keep the scope of this initial work as small as possible so that we can iterate quickly and not get stuck reinventing everything at once. --BDS _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
