+++ This bug was initially created as a clone of Bug #624373 +++ The mozilla drivers page is extremely out of date. Don't we have a new release drivers group or something? Or is the list of Mozilla release drivers located somewhere else? If so, the URL listed in this bug should point there.
I'm personally in favor of just getting rid of that page, or changing the list of drivers to just be a mailto: link to the release-drivers list.
I think it's important that people can see who the drivers are; just having a mailto: link doesn't offer that. There's also important role description on that page (although if it's out of date, we should fix that too). akeybl: is "the list of subscribers to firstname.lastname@example.org" now the canonical way of finding out who is a release driver? Or is there some other master list elsewhere? How many sets of drivers do we have in the rapid release world? Gerv
(In reply to Gervase Markham [:gerv] from comment #2) > I think it's important that people can see who the drivers are; just having > a mailto: link doesn't offer that. There's also important role description > on that page (although if it's out of date, we should fix that too). > > akeybl: is "the list of subscribers to email@example.com" now the > canonical way of finding out who is a release driver? Or is there some other > master list elsewhere? How many sets of drivers do we have in the rapid > release world? There is no explicit list of drivers at this point. The mailing list has turned into a coordination list, where those involved with releases in general can discuss (it's too large for the purposes of this bug). Final decisions are typically made through Release Management at this point, with input from security, engineering, and marketing/PR.
So who is in Release Management? "Drivers" is a Mozilla project function, not a MoCo function; if a MoCo department has taken over the role of a Mozilla project group, that might be a little concerning. Gerv
"Release Management" is currently Alex Keybl and Lukas Blakk. But as mentioned, there is no longer a centralized decision making authority akin to "drivers@", and in practice there hasn't been in a long time. I don't think it makes sense to try to create one. I think we've long ago grown past the point where that kind of simplified structure is useful (or usefully representative). Release Management is responsible for getting the answers, but they get those answers by coordinating with a number of different people and groups and driving consensus, not by making decisions in isolation. I think describing how release decision making actually works at Mozilla is a valuable endeavour, but the answer's going to be much more complex than "this list of people".
This page should be updated soon because it is easily accessible and is easily linked to by the following logic: From the mozilla.org page, (1) Click About (near the top) - https://www.mozilla.org/en-US/about/ (2) Click Governance - https://www.mozilla.org/about/governance.html (3) Click Roles and Responsibilities - https://www.mozilla.org/about/roles.html (4) Click Release Drivers - https://www.mozilla.org/about/drivers.html
Severity: normal → major
Version: unspecified → Trunk
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
This page is being reviewed as part of the Mozilla.org PHP > Python legacy migration project, so it'll either be archived or ported over, depending on its current relevance. In the meantime, if someone has SVN commit access, it wouldn't hurt to update the list or add firstname.lastname@example.org
Whiteboard: u=user c=content p=
++1 to delete this page. Anything more than deleting is a negative return on investment in my opinion. Why? Since 2013-1-1, this page has received 64 page views TOTAL. It gets an average of 5 page views a week which is pretty much zero. As a side note, this bug itself has received more page views (we have GA on BMO) in the past week than the drivers.html page that we are talking about. :)
I think Gavin has it right in comment 5. If this page is misleading about how release decisions are made at Mozilla, it's not helping. We should replace it with better documentation, but keeping the old page around as a forcing function for that isn't effective. Alex/Lukas: would you be able to write something which explains how Mozilla currently does release management, who is in the loop, how to contact the release managers for different products and branches, and so on? Or does that document already exist? Gerv
Isn't this content better suited for the wiki? Doing pull requests on github, having code changes reviewed by the Web Productions team, and then pushed out on a later date seems like a lot of work for simple text changes. Just because this content historically has lived on mozilla.org doesn't mean it has to live on the website going forward. If we want to write new content, do it on the wiki, and we can redirect this page to the wiki. akeybl: Is there an appropriate wiki page already? Let's wrap up this discussion in the next few days and have a clear next step.
cmore: comment 10 suggests that all mozilla.org website content changes will in the future have to be done via pull request and Web Productions team review; I seriously hope that's not the case! There are lots of documents on mozilla.org which need to be more permanent and stable than a wiki and yet need to be maintainable by their owners. However, I agree that the content I proposed in comment 9 would probably be OK on a wiki. Gerv
(In reply to Gervase Markham [:gerv] from comment #11) > cmore: comment 10 suggests that all mozilla.org website content changes will > in the future have to be done via pull request and Web Productions team > review; I seriously hope that's not the case! There are lots of documents on > mozilla.org which need to be more permanent and stable than a wiki and yet > need to be maintainable by their owners. > > However, I agree that the content I proposed in comment 9 would probably be > OK on a wiki. > > Gerv Yeah, Justin Crawford is looking into a method to allow quick content changes to mozilla.org by either using the current SVN framework or a easier github method for low risk pages. While github can be usedl like a light CMS, having to have code merged from other developers, pushed to dev, stage, and prod for a simple text changes is a bit overkill.
Could we redirect to https://wiki.mozilla.org/Firefox/Drivers and Alex/Lukas can update when they have time (or we could just link to the release management email list)?
(In reply to Gervase Markham [:gerv] from comment #9) > Alex/Lukas: would you be able to write something which explains how Mozilla > currently does release management, who is in the loop, how to contact the > release managers for different products and branches, and so on? Or does > that document already exist? Tried to keep it short and sweet. "Mozilla Release Drivers are the group of individuals that are entrusted with the coordination of Firefox releases, formally defined by membership in the mozilla-next-drivers Bugzilla group and the email@example.com mailing list. Since 2011 and the advent of the rapid release model, the Release Management Team has coordinated a majority of Firefox release work, from change approval based upon risk/reward to the tracking and resolution of critical release issues. Below is a list (updated 4/12) of all those drivers who offer their unique expertise and retain the ability to manage pre-release Firefox branches as well as their associated issues. Release Management Team - firstname.lastname@example.org email@example.com Alex Keybl firstname.lastname@example.org Bhavana Bajaj email@example.com Lukas Blakk Security firstname.lastname@example.org Al Billings email@example.com Curtis Koenig firstname.lastname@example.org Daniel Veditz Firefox Engineering email@example.com Benjamin Smedberg firstname.lastname@example.org Boris Zbarsky email@example.com David Baron firstname.lastname@example.org David Bolter email@example.com Mike Connor firstname.lastname@example.org Justin Dolske email@example.com Doug Turner firstname.lastname@example.org Dave Townsend email@example.com Ehsan Akhgari firstname.lastname@example.org Gavin Sharp email@example.com Johnathan Nightingale firstname.lastname@example.org Robert O'Callahan Platform Engineering email@example.com Bob Moss firstname.lastname@example.org David Anderson email@example.com Andreas Gal firstname.lastname@example.org Jeff Muizelaar email@example.com Joe Drew firstname.lastname@example.org Jonas Sicking email@example.com Josh Aas firstname.lastname@example.org Johnny Stenback email@example.com Justin Lebar firstname.lastname@example.org Jonathan Watt email@example.com Luke Wagner firstname.lastname@example.org Naveed Ihsanullah email@example.com Ted Mielczarek firstname.lastname@example.org Vladimir Vukicevic Mobile Engineering email@example.com Brad Lassey firstname.lastname@example.org Mark Finkle Project Management email@example.com Sheila Mooney firstname.lastname@example.org Dietrich Ayala email@example.com Lawrence Mandel Other Groups firstname.lastname@example.org Asa Dotzler email@example.com Chris Hofmann firstname.lastname@example.org Cheng Wang" (In reply to jbertsch from comment #13) > Could we redirect to https://wiki.mozilla.org/Firefox/Drivers and Alex/Lukas > can update when they have time (or we could just link to the release > management email list)? +1
Alex: If that content above is now accurate, can you just put it on the wiki so we can redirect this page to the wiki URL? I assume that is what you meant by the +1. Thanks!
Alex: that's great, thanks :-) Is that list organized functionally because each subgroup has a different role, or simply to show that release-drivers has expertise from each of those areas? +1 from me to wikifying that and putting in a redirect. Gerv
To show expertise, since they're not actually doing approvals/driving/tracking on a regular basis. Updated the wiki.
This redirect is live now and the wiki seems up to date, so I'm going to close this up. Please reopen if there's any other issues...
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.