957972 - Mozilla developers do not listen to community; no clear process for appeal

Status: RESOLVED DUPLICATE of bug 956988

(Firefox :: Untriaged, defect)

Description

[Nick]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0 (Beta/Release)
Build ID: 20121129183639

Steps to reproduce:

I found a usability bug in Firefox. I, along with many other users and web developers reported the issue to Mozilla via Bugzilla. We included many use-cases for why this bug should be fixed. The bug is here: https://bugzilla.mozilla.org/show_bug.cgi.

This, however, does not appear to be the only isolated case of Mozilla developers ignoring users and web developers.


Actual results:

No developers defended this decision or justified its necessity. Over the course of a year or more, many, many, comments were left on the bug, from people wanting it changed. No official response was ever given. 3 days ago, apparently Justin Dolske disabled comments. Apparently he was sick of hearing all this feedback from users? Or... something? Perhaps he should have simply unsubscribed himself? In any case, this issue highlights a huge problem at Mozilla: When users want to help improve the product, and one (presumably junior) developer at Mozilla does not like the idea, what is the recourse for the community? In this case, the developer was outvoted at least 100:1 on the issue by users, yet 100 people opposing the decision was not enough to change it. His final response? To hit the "shut up" button and disable comments.


Expected results:

We (the community) need a way of appealing decisions made by rogue Mozilla developers. A simple process where we can make a case, and the issue can be put to a vote. Everyone should be allowed to vote, not just Mozilla developers. The vote should be public. Firefox is supposed to be community software, by and for the community. This philosophy only works if the community has a meaningful say in major development decisions.

The overriding philosophy of FOSS is that no one person has all the answers. Others can contribute to the common goal of making the entire project better. This does not work when community members are trying to contribute, but are being ignored.

NOTE: This bug is submitted in all seriousness. It is not a technical issue, but a valid philosophical issue that **does** have a huge performance impact on the product, because the people who want to help make it better are being ignored, and being made to feel unappreciated and disrespected. This bug really needs fixed, via meaningful policy change.

If, however, Mozilla really doesn't care, go ahead and close this. But be sure to choose "WONTFIX", not "INVALID" as the reason. These concerns ARE valid, what you choose to do (or not do) about them is up to you. And I guarantee that if you leave this bug open, you will get people confirming that they too have experienced this bug first hand. I would also note, that if this is not the proper way to communicate organizational bugs, then you should provide a means for doing so elsewhere. (Besides a form where you can click a "Firefox makes me sad" face, then submit your gripe into a black hole never to be seen or heard from again.)

Comment 1

[Edmund Wong (:ewong)]

(In reply to Nick from comment #0)
> User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:17.0) Gecko/20100101
> Firefox/17.0 (Beta/Release)
> Build ID: 20121129183639
> 
> Steps to reproduce:
> 
> I found a usability bug in Firefox. I, along with many other users and web
> developers reported the issue to Mozilla via Bugzilla. We included many
> use-cases for why this bug should be fixed. The bug is here:
> https://bugzilla.mozilla.org/show_bug.cgi.

That's not a bug link, so I really don't know what bug your talking about.

> No developers defended this decision or justified its necessity. Over the
> course of a year or more, many, many, comments were left on the bug, from
> people wanting it changed. No official response was ever given. 3 days ago,
> apparently Justin Dolske disabled comments. Apparently he was sick of
> hearing all this feedback from users? Or... something? Perhaps he should
> have simply unsubscribed himself? In any case, this issue highlights a huge
> problem at Mozilla: When users want to help improve the product, and one
> (presumably junior) developer at Mozilla does not like the idea, what is the
> recourse for the community? In this case, the developer was outvoted at
> least 100:1 on the issue by users, yet 100 people opposing the decision was
> not enough to change it. His final response? To hit the "shut up" button and
> disable comments.
> 
> 
> Expected results:
> 
> We (the community) need a way of appealing decisions made by rogue Mozilla
> developers. A simple process where we can make a case, and the issue can be
> put to a vote. Everyone should be allowed to vote, not just Mozilla
> developers. The vote should be public. Firefox is supposed to be community
> software, by and for the community. This philosophy only works if the
> community has a meaningful say in major development decisions.
> 

Try mozilla.dev.apps.firefox or mozilla.support.firefox, and (
I could be wrong) but even mozilla.governance(?).

> The overriding philosophy of FOSS is that no one person has all the answers.
> 
> NOTE: This bug is submitted in all seriousness. It is not a technical issue,
> but a valid philosophical issue that **does** have a huge performance impact
> on the product, because the people who want to help make it better are being
> ignored, and being made to feel unappreciated and disrespected. This bug
> really needs fixed, via meaningful policy change.

While I don't doubt the seriousness how you filed this bug,  you're not
using the right 'method' of complaining about developers not listening to
users/web developers.  Bugzilla.mozilla.org is for filing actual bugs
in the software.


> 
> If, however, Mozilla really doesn't care, go ahead and close this. But be
> sure to choose "WONTFIX", not "INVALID" as the reason. These concerns ARE
> valid, what you choose to do (or not do) about them is up to you. And I

The word 'INVALID' points "The problem described is not a bug."
The word 'INVALID' does not mean your concerns are invalid.  You've got to 
use the right context for the right word.
This bug should probably be RESOLVED INVALID BUT HAS UNDERSTANDABLE CONCERNS
(or something like that). 

Seriously, you should try to use the right 'avenue' of expressing your
concerns.  bugzilla.mozilla.org, afaik, isn't the right avenue for this.

Comment 3

[Nick]

It looks like the URL got cut off. The bug link to the original is: https://bugzilla.mozilla.org/show_bug.cgi?id=641509.

I posted here because I was trying to find some other way to reach developers, with the hope of calling a vote, but I was unable to find any information on how or where to do that, or even what the decision structure is like when a feature or bug is disputed in how it should be handled. I would have continued commenting on the original bug, but comments were closed on it (without explanation or resolution). Before comments were closed, I asked how I could appeal the decision and got no response.

In the original bug linked herein above, the developer fixed a security problem, but went too far and created a new usability problem as a result. This is something that should have been debated, to create a solution that was secure and also beneficial to end users and web developers alike. In fact, there are many suggestions in the comments there about how to accomplish both goals. The problem is, no one who actually has commit powers was listening or caring. And it is incredibly frustrating to be ignored, when the active solution to the bug creates usability problems (since version 4, I think!), but a better solution is- well, honestly we have no idea why the "best of both worlds" solution is not being implemented. No one has given any valid reasons for not implementing it. If implemented as described in the comments, it would be both secure and useful.

Thanks you for mentioning other places to post. Are "mozilla.dev.apps.firefox", "mozilla.support.firefox", and "mozilla.governance" URLs? They don't load. It would be good if there were some way to get this on a meeting agenda for a vote or appeal so we could move forward on it.

Comment 4

[:Gijs (he/him)]

(In reply to Nick from comment #3)
> It looks like the URL got cut off. The bug link to the original is:
> https://bugzilla.mozilla.org/show_bug.cgi?id=641509.
> 
> I posted here because I was trying to find some other way to reach
> developers, with the hope of calling a vote, but I was unable to find any
> information on how or where to do that, or even what the decision structure
> is like when a feature or bug is disputed in how it should be handled. I
> would have continued commenting on the original bug, but comments were
> closed on it (without explanation or resolution). Before comments were
> closed, I asked how I could appeal the decision and got no response.

I've not read the entire bug and don't have time for it right now, but just to be clear, the decision appeal process (NB: not the 'how do we discuss about this', but the 'court of appeals' type hierarchy only) generally works like this:
a) decision gets made by the patch creator / bug assignee together with her or his reviewer (a peer/owner of the module that the code belongs to)
b) you can appeal to the module's owner if they weren't involved in (a)
c) failing that, you can appeal to Brendan Eich, who would be "the person where the buck stops", so to speak.

See also https://www.mozilla.org/en-US/about/governance/roles/ .

Furthermore, as debate has gone on for a long time in that bug and various dependencies/blockers related to that change (not just that bug itself), people are tired of having the same arguments over and over again. When posting to firefox-dev (see below) please be aware that the bar for revisiting this issue is high.

Your best bet would be offering a concrete alternative to the current implementation, and, as objectively as possible, outline (in that post, not just by referring elsewhere) how that addresses the original concerns that motivated the current solution and in which ways it's better and/or worse than the current solution for which groups of stakeholders ((different kinds of) users, web developers, code maintainers, etc.)

It'd probably be best to have this debate first. The Firefox peers and module owner read that list, and if you can convince them, I don't think it'll be necessary to get Brendan involved.

> In the original bug linked herein above, the developer fixed a security
> problem, but went too far and created a new usability problem as a result.
> This is something that should have been debated, to create a solution that
> was secure and also beneficial to end users and web developers alike. In
> fact, there are many suggestions in the comments there about how to
> accomplish both goals. The problem is, no one who actually has commit powers
> was listening or caring. And it is incredibly frustrating to be ignored,
> when the active solution to the bug creates usability problems (since
> version 4, I think!), but a better solution is- well, honestly we have no
> idea why the "best of both worlds" solution is not being implemented. No one
> has given any valid reasons for not implementing it. If implemented as
> described in the comments, it would be both secure and useful.

(I'm not engaging with this part of your response not because I wouldn't want to or am trying to be disrespectful, but because as Edmund pointed out, this isn't the right venue.)

> 
> Thanks you for mentioning other places to post. Are
> "mozilla.dev.apps.firefox", "mozilla.support.firefox", and
> "mozilla.governance" URLs? They don't load. It would be good if there were
> some way to get this on a meeting agenda for a vote or appeal so we could
> move forward on it.

They are newsgroups (NNTP). They are mirrored as mailing lists and on Google Groups. See https://lists.mozilla.org/listinfo . dev-apps-firefox is defunct in favour of firefox-dev, see https://wiki.mozilla.org/Firefox/firefox-dev (not available as a newsgroup/NNTP, but available as a moderated mailing list and google groups only). Considering the issue, I believe that is the best group to post to, possibly combined with dev-apps-platform .

In the interest of an open discussion, please link to some of the relevant bugs. In particular, if you haven't already, note bug 636374 (and all its duplicates with attack sites) and bug 616853 (ditto). onbeforeunload is a highly problematic feature from a security perspective, and any suggested solution should take this into account.