Re: Voting in BMO
On Thu, Jun 11, 2015 at 9:37 AM, Mark Côté wrote: > > * Change bug tagging to something like "favouriting" (or a word with > less contentious spelling ;). Rework the UI to provide an obvious > way to both favourite a bug and to see your favourites list. > ... > * After those are in place, turn Voting off for most if not all > products. > It seems to be a good plan. I guess it would be great if you could migrate all votes to favorite when you cut down Voting. - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Voting in BMO
On Wed, Jun 10, 2015 at 05:37:03PM -0400, Mark Côté wrote: > Thanks for all the input on this feature. This was a good discussion. > Here's what I've learned: > > * Almost no one makes decisions based on the number of votes > (Thunderbird and related may be an exception). > ** Ergo, most users voting on bugs are probably being misled into >thinking their vote accomplishes anything. > > * There is an idea that it cuts down on "me too" comments, but there's > no hard evidence. BMO also has more ways to hide or stop commenting > and to otherwise prevent abuse than it did a few years ago. > > * Some people use voting as a way to silently CC themselves onto bugs, > i.e., to not trigger CC mail (but see my aside below). > > * Some people are using voting to keep track of bugs without getting > much or any bugmail, presumably by unchecking most or all of the > "Voter" column in Email Preferences. > > (Aside: the default for new users is to only get CC mail if you are the > reporter. Admittedly this can still be annoying, it's not immediately > obvious how to disable it, and the value of notifications on CC changes > is highly questionable.) > > Thus it sounds like Voting is almost never used for its intended purpose > and could be actively misleading users. However, it also sounds like > people have discovered interesting alternative uses for it that could be > made more explicit, intuitive, and discoverable. > > I think we can cut out Voting and enhance other features along these lines: > > * Change bug tagging to something like "favouriting" (or a word with > less contentious spelling ;). Rework the UI to provide an obvious > way to both favourite a bug and to see your favourites list. > > * Further improve it to only display updates since you last looked at > the list, something like the "Updated Since Last Visit" feature in My > Dashboard. Ideally this would eliminate the need to get any bugmail > about favourites, but we *could* add it to the email preferences, > defaulting to no bugmail (I'd prefer to just rely on a dashboard, > though). > > * Turn off CC notifications entirely, with the possible exception of > when someone else CCs you on a bug. Note, I think it's perfectly fine to still mention CCs in bugmail when there is an accompanying comment, at least when the CC is not the person who comments (in which case it's more than fine, it's possibly useful). Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Voting in BMO
Thanks for all the input on this feature. This was a good discussion. Here's what I've learned: * Almost no one makes decisions based on the number of votes (Thunderbird and related may be an exception). ** Ergo, most users voting on bugs are probably being misled into thinking their vote accomplishes anything. * There is an idea that it cuts down on "me too" comments, but there's no hard evidence. BMO also has more ways to hide or stop commenting and to otherwise prevent abuse than it did a few years ago. * Some people use voting as a way to silently CC themselves onto bugs, i.e., to not trigger CC mail (but see my aside below). * Some people are using voting to keep track of bugs without getting much or any bugmail, presumably by unchecking most or all of the "Voter" column in Email Preferences. (Aside: the default for new users is to only get CC mail if you are the reporter. Admittedly this can still be annoying, it's not immediately obvious how to disable it, and the value of notifications on CC changes is highly questionable.) Thus it sounds like Voting is almost never used for its intended purpose and could be actively misleading users. However, it also sounds like people have discovered interesting alternative uses for it that could be made more explicit, intuitive, and discoverable. I think we can cut out Voting and enhance other features along these lines: * Change bug tagging to something like "favouriting" (or a word with less contentious spelling ;). Rework the UI to provide an obvious way to both favourite a bug and to see your favourites list. * Further improve it to only display updates since you last looked at the list, something like the "Updated Since Last Visit" feature in My Dashboard. Ideally this would eliminate the need to get any bugmail about favourites, but we *could* add it to the email preferences, defaulting to no bugmail (I'd prefer to just rely on a dashboard, though). * Turn off CC notifications entirely, with the possible exception of when someone else CCs you on a bug. * After those are in place, turn Voting off for most if not all products. Unless there are strong objections, we'll look into this in Q3. I realize this is not a huge change, but it's yet another step to make Bugzilla easier to use, particularly for new users. Look out for more posts like this in the future. Thanks, Mark ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Tracking bugs for preffing on Service Worker (1059784 for initial pref-on)
We're using this meta-bug to track shipping Service Workers to the release channel on desktop and Android: https://bugzilla.mozilla.org/show_bug.cgi?id=1059784 For B2G-specific Service Worker issues we're using this meta-bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1131322 And for "post-v1" bugs we're using this meta-bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1173500 When you're testing and filing bugs (of course you are), feel free to hang them off the "v3" meta-bug (1173500) or just file them in Core::DOM::Service Workers. Testing network interception in non-e10s mode is especially appreciated (because SW will hopefully ship first on a non-e10s release)! Thank you. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Firefox Data Collection Practices - How to Collect Data
I'd like to point Firefox and platform developers at this doc: https://wiki.mozilla.org/Firefox/Data_Collection Several times recently I've discovered that developers are unsure what the rules are for collecting data. Last year, I worked with Marshall Erwin to clarify decision-making about data collection and we came up with these guidelines and policies. The scope of my role as Firefox data steward includes understanding and reviewing the data the Firefox client sends back to Mozilla. This includes things like AUS pings, add blocklist pings, Firefox features that are delivered as a service (Hello, Accounts, Sync), as well as the actual data-collection features including telemetry, FHR, crash-reporting, heartbeat, etc. As necessary I will work with Marshall and Geoff from the legal team if there are legal concerns about any data, and to keep the Firefox privacy notice up to date. One of our biggest goals when doing data collection review is to ensure that the data collection is properly documented. For telemetry probes this may be self-documenting within Histograms.json itself, but for many other pieces of data, we will ask you to update the in-tree .rst docs to describe the data that is being collected. I have been listing out our existing data collection mechanism, many of which are not well-documented currently. You may see an email from me in the next few months asking for better docs for the existing data collection mechanisms. The data steward and data collection review replaces the older "privacy review" mechanism. Our goal is to review the data we collect not just privacy concerns, but to make sure that the data will be able to answer the questions you want to ask and that there is somebody responsible for monitoring the data after it has been collected. I would like to review all changes to data collection, including new telemetry probes, crash-stats annotations, etc. Vladan Djeric and Ally Naaktgeboren are my peers to help expedite data collection reviews: feel free to request review from any of us. Please let me know if you ever feel stuck or blocked on data review: my goal is to get simple requests approved very quickly, and make sure more complex requests don't ever get stuck or have a clear owner. My role as Firefox data steward does not extend to Firefox OS: the data steward for Firefox OS is Jonas Sicking. Also, my role does not extend to the servers which store data after it has been collected: the Firefox cloud services data steward is Travis Blow. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: Allocating FallibleTArray methods will soon require `mozilla::fallible` argument
Greetings, Over in bug 968520, FallibleTArray is being merged into nsTArray. After the bug is complete, we will be left with just nsTArray (and nsAutoTArray). Fallible allocation will be opt-in using the `mozilla::fallible` parameter just like with ns*String. As a first step in this transition, it will soon be required to pass `mozilla::fallible` to allocating FallibleTArray method calls. Note that you can already use `mozilla::fallible` with both nsTArray and FallibleTArray (and their Auto variants): nsTArray array; array.SetCapacity(10); // Infallible bool result = array.SetCapacity(10, fallible); // Fallible FallibleTArray array; array.SetCapacity(10); // Compile error (soon) bool result = array.SetCapacity(10, fallible); // Fallible The commit to enforce this behaviour for FallibleTArrays will land on mozilla-inbound shortly. For more information, see: https://bugzilla.mozilla.org/show_bug.cgi?id=968520 Cheers, Biru ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Voting in BMO
On 2015-06-10 7:06 AM, Philipp Kewisch wrote: > I could live without this feature if the number of people on CC gives > some indication of how wanted a feature may be. Can you check > correlation between the number of votes and the number of people on CC? A quick scan of the Core & Firefox products reveals a fairly high correlation amongst bugs with many votes, around an average of 0.8 for the top 10 most voted bugs, if my math is correct. Unfortunately there's no easy way to search for the complement, i.e. if bugs with high CC counts have lots of votes, but I think that is less interesting (maybe?). Mark ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Voting in BMO
Philipp Kewisch schrieb: I could live without this feature if the number of people on CC gives some indication of how wanted a feature may be. Well, I tend to CC myself to thing I seriously do not want to change but really want to be informed about when they actually get done. I wouldn't use votes for that. ;-) KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The War on Warnings
I'm 99% sure we've had mis-stars on intermittent assertion oranges where the assertion changed and nobody bothered checking the logs to notice. Various media tests are coming to mind for when that's happened. On 6/10/2015 10:10 AM, Ehsan Akhgari wrote: On 2015-06-10 3:38 AM, David Rajchenbach-Teller wrote: However, I do believe in the following scenario: - oh, there is an assertion warning, it's not my fault, let's allow one assertion; - wait, there are a few, let's allow several; - oh, they are intermittent, let's make it an interval; - [at some point, some of the warnings are fixed, but nobody realized]; Yes, assuming the number of assertions doesn't fall outside of the range, of course. - [at some point, something causes other warnings to be triggered, but nobody realized]; - we realize the regression years later. Yes, like I said, I agree this problem exists _in theory_. I however think that it's unlikely. (Note that we currently have only 82 SimpleTest.expectAssertions annotations in our tests, so we're already talking about an edge case of something that is extremely uncommon itself. :-) I am almost sure that I have witnessed this kind of scenario while working on Session Restore. It used to cause assertion warnings at some place in the DOM, which were not documented in any bug that I could find, and nobody cared. Concrete examples would help. I can't find any test in browser/components/sessionstore right now with an assertion annotation so it's hard to say what the exact issue that you saw was, but I think you are complaining about the lack of documentation and that nobody cared. Neither of those issues will be solved with what you are suggesting. Also, second issue of the current approach: I have seen very few (if any) bugs yet that documents exactly the assertion warnings that they trigger, explaining why they are normal and should be ignored. That's a codetrap for whoever comes next. Requiring a test to actively opt-in for whitelisting a specific assertion warning means that there is a good place to r- the test until this is documented. Not necessarily. Reviewers can choose to require exactly that everywhere SimpleTest.expectAssertions is used (I for one try to do that, but these are so rare that I can't remember the last time I reviewed such a test very well...) My point is, changing |SimpleTest.expectAssertions(2)| to |SimpleTest.expectAssertions(["first assertion message", "second assertion message"])| doesn't really give us much besides the ability to pinpoint the expected assertions to the exact assertions that the test triggers. And I'm not saying that is not valuable, it's just a solution to an extremely rare problem. Issues such as lack of documentation of why the test is triggering an assertion are orthogonal to the syntax we use to declare the whitelist. Frankly, I'm really sick of warnings, and anything we can do to make them more actionable would be one step towards restoring sanity in our tests and in some parts of our codebase. Warnings are different. There is basically a spectrum of things you can do, from setting the MOZ_IGNORE_WARNINGS (and MOZ_QUIET) environment variables if you're just annoyed with them and don't want to see them, to filing bugs for the ones that happen way too often in tests (or during common operations such as opening a tab, typing something in a form, etc) and CCing the relevant people and asking whether the warning can be silenced, etc. I very much welcome the latter and have tried to act on such bugs where I can. Right now we have so many warnings that a project to annotate every test with every single warning that it generates is *really* impractical. And once we fix the problem of having too many frequently occurring one, the value of such a project is heavily diminished. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Voting in BMO
On 2015-06-09 11:58 PM, Wayne wrote: >> That said, there are much bigger issues with Bugzilla's UI, and removing >> voting is probably the smallest possible improvement. But it's probably >> easy to just disable it for a while, and see what happens? > > I never have seen the voting UI as being the least bit distracting. So > I'd completely agree, other things in the UI are FAR more deserving of > attention and discussion. Just imagine the fun we're going to have when we bring up changing or removing anything decidedly less trivial. :D In all seriousness, this thread has brought up a number of interesting points. Removing the feature may have been my original goal, but now I'm realizing the strange ways that some features are (mis)used, and that some of our existing features should be reoriented slightly to be made better. This has been good user research. Mark ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The War on Warnings
On 2015-06-10 3:38 AM, David Rajchenbach-Teller wrote: However, I do believe in the following scenario: - oh, there is an assertion warning, it's not my fault, let's allow one assertion; - wait, there are a few, let's allow several; - oh, they are intermittent, let's make it an interval; - [at some point, some of the warnings are fixed, but nobody realized]; Yes, assuming the number of assertions doesn't fall outside of the range, of course. - [at some point, something causes other warnings to be triggered, but nobody realized]; - we realize the regression years later. Yes, like I said, I agree this problem exists _in theory_. I however think that it's unlikely. (Note that we currently have only 82 SimpleTest.expectAssertions annotations in our tests, so we're already talking about an edge case of something that is extremely uncommon itself. :-) I am almost sure that I have witnessed this kind of scenario while working on Session Restore. It used to cause assertion warnings at some place in the DOM, which were not documented in any bug that I could find, and nobody cared. Concrete examples would help. I can't find any test in browser/components/sessionstore right now with an assertion annotation so it's hard to say what the exact issue that you saw was, but I think you are complaining about the lack of documentation and that nobody cared. Neither of those issues will be solved with what you are suggesting. Also, second issue of the current approach: I have seen very few (if any) bugs yet that documents exactly the assertion warnings that they trigger, explaining why they are normal and should be ignored. That's a codetrap for whoever comes next. Requiring a test to actively opt-in for whitelisting a specific assertion warning means that there is a good place to r- the test until this is documented. Not necessarily. Reviewers can choose to require exactly that everywhere SimpleTest.expectAssertions is used (I for one try to do that, but these are so rare that I can't remember the last time I reviewed such a test very well...) My point is, changing |SimpleTest.expectAssertions(2)| to |SimpleTest.expectAssertions(["first assertion message", "second assertion message"])| doesn't really give us much besides the ability to pinpoint the expected assertions to the exact assertions that the test triggers. And I'm not saying that is not valuable, it's just a solution to an extremely rare problem. Issues such as lack of documentation of why the test is triggering an assertion are orthogonal to the syntax we use to declare the whitelist. Frankly, I'm really sick of warnings, and anything we can do to make them more actionable would be one step towards restoring sanity in our tests and in some parts of our codebase. Warnings are different. There is basically a spectrum of things you can do, from setting the MOZ_IGNORE_WARNINGS (and MOZ_QUIET) environment variables if you're just annoyed with them and don't want to see them, to filing bugs for the ones that happen way too often in tests (or during common operations such as opening a tab, typing something in a form, etc) and CCing the relevant people and asking whether the warning can be silenced, etc. I very much welcome the latter and have tried to act on such bugs where I can. Right now we have so many warnings that a project to annotate every test with every single warning that it generates is *really* impractical. And once we fix the problem of having too many frequently occurring one, the value of such a project is heavily diminished. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Voting in BMO
On 2015-06-10 3:55 AM, Mark Banner wrote: Replying to this got me thinking - what about changing "vote" to "I have this issue" similar to support.mozilla.org. However, I think the usefulness would end up in the same way as voting. As a suggestion though, how about adding something near the comment box - like a checkbox or button which says "I have this issue and wish to receive updates about it". If it was a checkbox, it could disable the comment box. For what it's worth, I think that the combination of this and disabling notification for cc changes is a pretty strong idea, even if doesn't quite achieve the holy grail of feature removal. - mhoye ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Voting in BMO
On 6/10/15 1:24 PM, Dirkjan Ochtman wrote: > Similarly, I could imagine that the very explicit CC list could be > changed to be more like a Follow button, plus a (simplified) way to > include others for those who have relevant privileges. Have you seen the experimental bugzilla UI? It has a "follow" button. https://globau.wordpress.com/2015/03/31/bmo-new-look/ Philipp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Voting in BMO
On Tue, Jun 9, 2015 at 11:09 PM, Mark Côté wrote: > To that end, I'd like to consider the voting feature. While it is > enabled on a quite a few products, anecdotally I have heard > many times that it isn't actually useful, that is, votes aren't really > being used to prioritize features & fixes. If your team uses voting, > I'd like to talk about your use case and see if, in general, it makes > sense to continue to support this feature. Perhaps a good solution would be to morph voting into a less complex feature. I.e., it could be more like GitHub stars, where you have a way to note your interest without retrieving regular updates; just a binary state for every user/issue, with a single clickable UI element. Similarly, I could imagine that the very explicit CC list could be changed to be more like a Follow button, plus a (simplified) way to include others for those who have relevant privileges. Cheers, Dirkjan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Voting in BMO
On 6/9/15 11:09 PM, Mark Côté wrote: > To that end, I'd like to consider the voting feature. While it is > enabled on a quite a few products, anecdotally I have heard > many times that it isn't actually useful, that is, votes aren't really > being used to prioritize features & fixes. If your team uses voting, > I'd like to talk about your use case and see if, in general, it makes > sense to continue to support this feature. I have actually used votes in the past to aid decision making on what feature to implement next. I am aware that votes will not tell me how severe a normal bug is, but it does allow for prioritization of enhancement bugs in moments where you think "ok, so what feature would the user like to see next..." I could live without this feature if the number of people on CC gives some indication of how wanted a feature may be. Can you check correlation between the number of votes and the number of people on CC? Philipp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Voting in BMO
Original-Nachricht Betreff: Voting in BMO Von: Mark Côté An: Datum: 2015-06-09 23:09 To that end, I'd like to consider the voting feature. While it is enabled on a quite a few products, anecdotally I have heard many times that it isn't actually useful, that is, votes aren't really being used to prioritize features & fixes. If your team uses voting, I'd like to talk about your use case and see if, in general, it makes sense to continue to support this feature. Thanks, Mark That would leave only relationship role to a bug (CC) which everybody can use. I use CC for bugs where I have to read the comments and votes where I am only interested if the status or dependency tree changes. If I always have to CC myself, the increased bug mail count will make reading bug mail more time consuming. Sebastian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Voting in BMO
Regarding CC instead of voting, there is another issue. Voting is not enabled in every component, so on these bugs I add me to the CC list. But sometimes it happens that a bug will be marked as confidential after I added me to the CC list. In that case I have still access to the not public bug. This cannot happen with votes. It already happened more than one time. ;) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Voting in BMO
On 09/06/2015 23:19, R Kent James wrote: Without voting, how do you direct users to express an interest in seeing a bug solved without adding a "me too" comment? Maybe the answer is that we don't. We just need to be honest - it would be very difficult to create a fair system that could be used in a valid way. Allowing votes by users that then don't actually get looked at or considered, is just misleading the user who's taken the time to create an account, sign-in and then vote. Replying to this got me thinking - what about changing "vote" to "I have this issue" similar to support.mozilla.org. However, I think the usefulness would end up in the same way as voting. As a suggestion though, how about adding something near the comment box - like a checkbox or button which says "I have this issue and wish to receive updates about it". If it was a checkbox, it could disable the comment box. I'm not sure if that could also be misleading, but the intention would be to add an option for a user to give them something other than just the comment box - which at the moment, is the only real obvious "associate me" with this bug option. Mark. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The War on Warnings
However, I do believe in the following scenario: - oh, there is an assertion warning, it's not my fault, let's allow one assertion; - wait, there are a few, let's allow several; - oh, they are intermittent, let's make it an interval; - [at some point, some of the warnings are fixed, but nobody realized]; - [at some point, something causes other warnings to be triggered, but nobody realized]; - we realize the regression years later. I am almost sure that I have witnessed this kind of scenario while working on Session Restore. It used to cause assertion warnings at some place in the DOM, which were not documented in any bug that I could find, and nobody cared. Also, second issue of the current approach: I have seen very few (if any) bugs yet that documents exactly the assertion warnings that they trigger, explaining why they are normal and should be ignored. That's a codetrap for whoever comes next. Requiring a test to actively opt-in for whitelisting a specific assertion warning means that there is a good place to r- the test until this is documented. Frankly, I'm really sick of warnings, and anything we can do to make them more actionable would be one step towards restoring sanity in our tests and in some parts of our codebase. Best regards, David On 10/06/15 06:39, Ehsan Akhgari wrote: > On 2015-06-09 8:33 AM, Robert O'Callahan wrote: >> Does anyone know of a case where we had a regression that traded one >> assertion for another? I don't. > > I don't either. Which is why I believe that David's point, while being > perfectly valid in theory, doesn't matter a lot in practice. > > Also, you need to consider the fact that one assertion appearing in > place of another one in the same commits going into one build compared > to the previous not breaking *anything else* or have any observable > effect on all of our test suites is extremely unlikely. -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
