gmane.comp.mozilla.devel.seamonkey

Re: Group icons in Bugzilla

Gervase Markham — 2008-08-30T10:26:46

Absolutely. But authority is not binary either. I think that's at least possible - my strong objection is to that icon being any of the project or product icons. Gerv

Re: Group icons in Bugzilla

Gervase Markham — 2008-08-30T10:23:14

Sadly not possible with this technology - it's groups-based. Gerv

Re: Group icons in Bugzilla

Gervase Markham — 2008-08-30T10:28:42

I'm not sure that's true. This feature was briefly (like, for a few hours) deployed after the upgrade, and I argued strongly for removing the icons before this discussion, precisely because people wouldn't then feel like something was being taken away from them. If we try it (at least, if we try it with the product/project icons) and it causes community division and arguments, and then we tweak it or remove it, people are going to feel aggrieved. ("You mean, you no longer think I'm worthy of...") Gerv

Re: Group icons in Bugzilla

Gervase Markham — 2008-08-30T10:24:23

Sticky to the user - it would show the SeaMonkey icon. No, because he would be removed from the drivers group. Gerv

Re: Group icons in Bugzilla

Justin Dolske — 2008-08-30T07:17:03

Perhaps, although I worry a bit about becoming a group of green-starred Sneetches. :-) I also wonder if it will make much of a difference... Seems like when these kinds of issue pop up, it's not because a user simply didn't understand who someone is. More often it's someone demanding their bug be fixed, pet-peeve UI be changed, etc. (MNG bug, I'm looking at you!). Won't hurt to try it out. We can always revert if it's a problem. Justin

Re: Group icons in Bugzilla

Justin Wood (Callek — 2008-08-30T02:25:32

Of interest are these icons sticky with respect to the comment itself [ie. date/time], or is it sticky to the user (ex, if in 2 years I get a seamonkey icon, and someone looks at a comment I made in a calendar bug when I started using bugzilla, will that show seamonkey icon, or not) (also ex. If we use it for drivers, and Beltzner gets a firefox icon, but next year he takes a job at google and doesn't work on firefox anymore. Will he still have that icon for his comments today?) I feel the answer to this clarification on the feature will better inform our decision to use it.

Re: Group icons in Bugzilla

chris hofmann — 2008-08-30T03:09:09

You are using the words "hierarchy" and "authority" a lot above, and you are setting this up against democracy and egalitarian decision making. I don't think we have been, nor should we become, either of those kinds of organizations. The tendency of "hierarchy" and "authority" over time is to try and stamp out idea that don't fit some norm. The tendency of democracy and egalitarian system is to debate the ideas endlessly, or just vote to reach some decision. Both of these systems can work in the short run, but are pretty dangerous over time. From the very early days we have tried to create a meritocracy. A meritocracy tries to encourage and search out the best ideas, examine them, and come to decisions and working solutions that have peer review from people with knowledge and experience in the area. If we still want to be a meritocracy we shouldn't be putting any badges on people. We should be putting badges on good ideas, convincing arguments, and working solutions that are wel

Re: Group icons in Bugzilla

Mike Connor — 2008-08-30T01:19:31

To some extent, it _is_ what we want to say... this is not a democracy, this is not a egalitarian group where everyone speaks with the same authority. There's a somewhat complicated and always-evolving structure, and to a casual observer there's no way of indicating who a person is, or what roles they play within Mozilla. Having a small icon with a useful group description as a tooltip would go a _long_ way towards helping casual members of the community identify who they're talking to. One reason it would be handy would be to clearly identify the people who have responsibility and ownership over issues. Some random bug filer has no way of knowing who does and doesn't have authority to make calls on bugs, or which opinions are actually coming from the people in the position of responsibility. Its entirely different if I make a statement about our intentions than if someone who happens to have editbugs makes that statement. (I've seen my share of angry blog comments about something "the F

Re: Bugzilla improvements

Zack Weinberg — 2008-08-30T00:22:30

... I'm coming at this from the opinion that we need, as a matter of policy, to accept unhelpful comments on any bug at any stage of its life. The bug system isn't just for the developers; it is also one of the only venues where users affected by a problem can find each other and commiserate, discuss workarounds, vent, &c. I see intrinsic value in providing that venue *even if* it doesn't help get bugs fixed. If that means we need technical measures whereby individual bugzilla users can do something to filter out the comments they see as distraction, well, let's make that happen. (I think it's okay if, in a bug like, oh, 915, all the venting goes unanswered by developers.) Only if there is a crystal-clear, public policy defining vandalism. Otherwise we're going to get accused of censorship. (I have yet to see actual spam on bugs, or the sort of thing you see on Slashdot at -1, and I'm not sure I would delete anything short of that.) zw

Re: Bugzilla improvements

Joshua Cranmer — 2008-08-29T23:26:58

As I see it, a bug has several stages: 1. The first stage, where developers haven't really picked it up. This combines both UNCO and early NEW stages. 2. The second stage, where developers have looked at it and are pondering how to implement it. Late NEW and early ASSIGNED. 3. The third stage, where the bug is going through review cycles. I'm including in this stage cases where the fix was backed out and then put back in, so that it doesn't really end until it "sticks." Mostly the ASSIGNED and REOPENED (maybe) stages. 4. The last stage, where people find regressions, etc. from the bug. (This only deals with bugs which are ultimately fixed. Other bug types have different cycles). I can tolerate the "me too," etc., comments in stage 1. By the later stages, though, people complaining about the lack of the fix (or the time it took to fix) are really aggravating, since it makes technical discussion difficult. Also not helpful are where a bug of high complexity spawns real work into dependencies and p

Re: Branch management suggestions, redux

Igor Bukanov — 2008-08-29T23:02:14

2008/8/29 Gervase Markham mozilla.org>: He is cloning the bug because the policy requires it, like the need to clone for separated branches or products, not because the bug diverges. Which shows that the real problem with cloning for branch bugs is bad GUI: one can not see aggregated comments for the bug and clones on the same page. Regards, Igor

Re: Bugzilla improvements

Zack Weinberg — 2008-08-29T22:57:48

I didn't realize how bad it was already - thanks. Under these conditions, I'd argue that hiring more customer-support people would be a better use of available funds than hiring more devs. I'd much rather see us be able to sort, assign, and fix all of those bugs than get a few more features for FF.next. I hear you, but I don't think it's necessary to scare people away in order to reduce the influx of useless reports. We can ask the same questions, or effectively so, in a more subtle way. For instance, the attached file is a suggestion for how the "please don't re-report these bugs" screen could be better. ... ... I don't know. Ask me again after I'm getting 10 times as much bugmail. :) zw_______________________________________________ dev-planning mailing list dev-planning< at >lists.mozilla.org https://lists.mozilla.org/listinfo/dev-planning

Fennec Status Meeting, Tuesday September 2 < at > 9AM PDT

Stuart Parmenter — 2008-08-29T21:51:59

Hey guys, Due to labor day in the US and Canada, most folks will be off on Monday the 1st, I've rescheduled our meeting for Tuesday. As normal, please add the stuff you've been working on, things you're planning on working on, or issues you're blocked on to the wiki page below so that we can go over them on Monday. Meeting Details: * Agenda: https://wiki.mozilla.org/Mobile/Notes/2-Sept-2008 * *Tuesday*, September 2, 9:00 am PDT * 650-903-0800 x91 Conf# 314 (US/INTL) * 1-800-707-2533 (pin 369) Conf# 314 (US) * join irc.mozilla.org #mobile for back channel cheers, stuart

Re: Bugzilla improvements

Clint Talbert — 2008-08-29T21:57:27

I would agree with you. I'll propose my traige team post and we can try to understand how to deal with this scale. ..snip.. I like your idea about a set of questions. The current form tries to do that, but it could ask better questions. I agree with you. The fact that people comment isn't the problem. I would never tell people not to comment -- those comments are where the rubber meets the road in terms of a FOSS project. I'm just stating that it is a lot to deal with, so the 500 number is a little low. I think we do this with the current system. I don't think that part is broken. Clint

Re: Bugzilla improvements

Michael Lefevre — 2008-08-29T21:37:16

I wouldn't say that it's a future possibility that QA (or rather "current triaging work") won't scale. It failed to scale some time ago and is nowhere near keeping up - lots of bug reports never get triaged usefully and go nowhere (unless there has been some miraculous catching up recently that I haven't noticed, but there are 7000 open bugs in Firefox General, and 6200 of them are UNCOnfirmed, and those numbers are going up all the time). I'm not sure throwing people at the current system would work too well either... Although if that kind of thing is possible and there's room in the budget, can we hire a whole bunch of developers instead and get Firefox 4 finished next month? :) With the current state of things, I'm afraid I don't necessarily think that's bad. Obviously it's a pretty horrible way of doing it, but scaring away some people who don't try as hard at making bugzilla work means you have got rid of a pile of useless reports before they have been made - maybe you lose a few good ones too, but

Re: Group icons in Bugzilla

Mike Connor — 2008-08-29T21:37:45

Any group icons would only make sense in the context of _existing_ groups, which have existing rules for membership/inclusion. If there isn't a need for a group, I don't think it'd make sense to create one in Bugzilla alone.

Re: Bugzilla improvements

Clint Talbert — 2008-08-29T21:33:37

I think we have a situation where people feel responsible to get things triaged, but just can't keep up, given their other responsibilities. The first proposal here sounded like we wanted to push that responsibility to the QA team (corporate QA team + active triaging community) and I didn't see how that would scale. That's how I read the original post. As an organizational strategy, putting stuff into a pile "to be organized later" never really works unless there are dedicated people to organize that stuff on continuing basis. The original proposal sounded to me like we were volunteering QA to be that set of dedicated people, which is why I was saying it wouldn't scale. I've since walked away from the discussion for a moment and come up with an idea on how to handle this a bit, I'll propose it at the end. ..snip.. This thought gets me much closer to a the solution I came up with when I walked away for a bit. I agree with you (and Zack's point in his follow on post) that the user facing si

Re: Group icons in Bugzilla

Justin Dolske — 2008-08-29T21:20:03

Agreed. I think it would be a huge waste of time to have such arguments. Seems like it would be easier to just let any user pick any icon (ala Digg), or have a very very small number of users who can have icons for really good reasons. [I'm not what those compelling reasons would be.] Justin

Re: Group icons in Bugzilla

Gervase Markham — 2008-08-29T20:23:45

I think the general feature may have been added so that a public-facing Bugzilla owned by a company could label all the employees. Or, as suggested by the 3.2 release notes, "to distinguish developers from bug reporters". https://bugzilla.mozilla.org/show_bug.cgi?id=332149 is the original bug. At one point, Mike, you said "Just adding this to my design radar. :)" :-) Gerv

Re: Group icons in Bugzilla

chris hofmann — 2008-08-29T20:36:26

we ought to strive for being gentle and civil to both new and old contributors. ;-) we should also try and judge the each bug and act on the bug on the merits and quality of the information in the report. people new to the project should understand that. its also the case that new people to the project can have great ideas too, so we shouldn't give new participants any kind of newbie label that assigns them to a sub-class... Along those lines there might be some interesting perspectives here... In this book there is a good definition of the "roles" in a startfish organiziation. http://www.starfishandspider.com/ A starfish, and a starfish organization is very decentralized with no central point for coordination. Its regenerative. If you cut off part of the structure it can regrow. Each of the tenticales (communities and module owners) need to convice the rest of the organizim to move it a direction that seems right. It happens though peer review and explaining a vision of what migh

Re: Bugzilla improvements

Tim Riley — 2008-08-29T20:31:22

Wow, Bug Day mega force! I'd like to see that huge army of QA community members! ;) The reality is that they do great work on verifying bug fixed, confirming bugs, adding STRs, identifying regression ranges, helping with qawanted. But this only adds up to a few people-*days* worth of work per week. Not the maybe 10 people-*weeks* worth of effort needed just to keep up with the hundreds incoming bugs per week. The bottom line is: There is no easy way to simply throw people at this without dramatically impacting other equally as important activities like adding STRs, testing features, etc. This may sound fatalistic. I do not mean that. I think we can improve the situation by setting up the right teams (dev, QA, and support?) or cycling people through the task of reviewing incoming bugs like we do for sheriffs and tiger team testing. --Tim

gmane.comp.mozilla.devel.seamonkey

Re: Group icons in Bugzilla

Re: Group icons in Bugzilla

Re: Group icons in Bugzilla

Re: Group icons in Bugzilla

Re: Group icons in Bugzilla

Re: Group icons in Bugzilla

Re: Group icons in Bugzilla

Re: Group icons in Bugzilla

Re: Bugzilla improvements

Re: Bugzilla improvements

Re: Branch management suggestions, redux

Re: Bugzilla improvements

Fennec Status Meeting, *Tuesday* September 2 < at > 9AM PDT

Re: Bugzilla improvements

Re: Bugzilla improvements

Re: Group icons in Bugzilla

Re: Bugzilla improvements

Re: Group icons in Bugzilla

Re: Group icons in Bugzilla

Re: Group icons in Bugzilla

Re: Bugzilla improvements

Fennec Status Meeting, Tuesday September 2 < at > 9AM PDT