User:Hsinyi/Gecko engineering

From MozillaWiki
Jump to: navigation, search

<Disclaimer: This document is a draft and a collection of my personal thoughts of gecko engineering practices.>

What should I work on?

We want to deliver a product with high qualities to our users, we want to bring new values to our users. This won't happen without collaboration with various teams and our community. Therefore, when we are thinking about what we should work on with which priority, we consider to unblock others and help others as well. Here is a list (in descending order of priority) to show others how our work is being prioritized, not necessarily a how to strictly prioritize the work.

  • Catastrophic bugs
    Bugs that block development/testing, may impact more than 25% of users, causes data loss, potential chemspill, and no workaround available. Examples include but not limit to:
    1. sec-critical security bugs
    2. Sev-blocker or release-tracking+ bugs
    3. Permanent test failures that block branch merging
    4. New regressions: Not every regression is a catastrophic issue, but we should look into quickly to investigate the impact and solutions timely.
  • Review and needinfo requests to unblock others
    Browser is such a complex system. No one knows every single piece or no one can figure out every single piece shortly. Only when we have collaborative team work, are we able to deliver a satisfying product or bring new values to our users timely. (Yes, TIMELY again!) It takes time and effort to build a product with high qualities, no doubt. I am not saying we should sacrifice the quality. What I am trying to say here is we have to admit the time-to-market impact or how the life cycle of a bug impacts our user, keep that in mind and guide our work. So with that in mind, unblocking others is a key for us to succeed.
    To do a proper and thorough and high-quality review may take time. And we should take what it needs to ensure our quality. Communication is nevertheless a key here. If it takes longer to review/respond, communicate. If you are not sure about the priority, communicate. Oh, and, if it's a simple enough review or question (even the priority isn't high), just do it and help things done.
  • Serious bugs
    Bugs that cause major Functionality/product severely impaired. If there's a satisfactory workaround, for example, flipping a preference and explaining to our users about this so they can live with it, we should do it. sec-high security bugs are one example for this category, as well as top crashes. Again, keep an eye on regressions.
  • Special programs e.g. WFH bugs, q-flow bugs
    To react upon the real world situation, priorities change for a given period of time. COVID-19 is an example of how people's working, social and daily lives are largely impacted and changed in a certain period. Some old issues may become much more sever due to this.
  • Important partner and webcompat bug fixes
  • Bug fixes
  • New features

Add some notes for tests and documents.

Bug triage

References:

Layout team triage

DOM team triage

Code review

Release health and product quality

Roadmap and status communication