search

mozilla / webcompat-team-okrs

These are quarterly team level OKR projects for the WebCompat Tools team
Mozilla Public License 2.0
11 stars 7 forks source link

Better cooperation in between Relman Team and Webcompat Team #254

Open karlcow opened 2 years ago

karlcow commented 2 years ago

The relman team has for objectives stability and no surprises. The webcompat team is working on an assumption of emergency and reactivity (nature of the work).

Both team objectives create frictions and probably misunderstandings on the nature of the work.

We need to better explain what each of the team do (That would be perfect if All Hands or work week were still possible.) Some items we need to address

  1. Explainer and understanding of relman work
  2. Explainer and understanding of webcompat work
  3. List release-drivers: what does it do? Should webcompat team have an impact on it?
  4. Should webcompat team nominate bugs to track for a release or is it the responsibility of the core team in which the bug is opened?
  5. Site Interventions and Releases are tightly coupled. Pros and Cons.
  6. How to define on mid-term to long-term what is being released on the Platform. Currently the Core team is often asking the webcompat team about the priority for some Core Platform bugs.
  7. Explain the Webcompat Priority on Core Bugs, see.

Let's try to address these and see if we can have a better cooperation or at least better understanding.

karlcow commented 2 years ago

@pascalchevrel if there are more questions and comments could you add them here. And we can open separate issues, little by little to address them.

karlcow commented 2 years ago

@ksy36 has opened a bug for better tracking regression on web-bugs

karlcow commented 2 years ago

Interesting case for the discussion. https://github.com/webcompat/web-bugs/issues/99281#issuecomment-1033303257

pascalchevrel commented 2 years ago

Interesting case for the discussion. webcompat/web-bugs#99281 (comment)

yes, had we known that this would cause a webcompat issue, we would most likely have uplifted the patch to 96.

karlcow commented 2 years ago

Interesting case for the discussion. webcompat/web-bugs#99281 (comment)

yes, had we known that this would cause a webcompat issue, we would most likely have uplifted the patch to 96.

except we could not :) The webcompat issue has been opened 2 days ago.

pascalchevrel commented 2 years ago 
1. Explainer and understanding of relman work

The relman team organizes the shipping of our Firefox products for desktop and mobile (with the exception of Firefox for iOS). This is cross-functional work, we work with all mozilla department from legal to platform.

We monitor all the patches that land in nightly, organize uplifts to our betas and releases when needed, manage the release calendar, crashes, performance, release notes, and generally speaking we try to ship the best possible Firefox every 4 weeks (every 2 weeks with dot releases). We have a strong focus on fixing regressions before we ship a new version to the release channel. To this effect we uplift between 100 and 150 patches to beta and release candidates every cycle that we have identified will improve the quality of life for our users and consequently improve user retention.

3. List release-drivers: what does it do? Should webcompat team have an impact on it?

This list is used to announce the progress of all Firefox builds during the cycle. This is also the list where we announce upcoming dot releases for which we accept ride-along patches, which is an important information for uplift nomination.

  1. Should webcompat team nominate bugs to track for a release or is it the responsibility of the core team in which the bug is opened?

If the bug has a webcompat impact, the webcompat team should reach out to the relman team (preferably via a tracking request on Bugzilla) just like other teams do. For example the accessibility team nominates bugs for tracking that are outside of their own component because they have an impact on accessibility.