User:Hsinyi/Gecko engineering

<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

  Blocks 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. 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

  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. Again, keep an eye on regressions.

• Special programs e.g. WFH bugs, webcompat bugs

• Important partner bug fixes

• Bug fixes

• New features

Add some notes for tests and documents.