Minutes of the mozilla.org Staff Meeting of Wednesday 26th February 2003

Wednesday March 5th, 2003

The minutes of the mozilla.org staff meeting of Wednesday 26th February 2003 are now online. Issues discussed include Camino, the 1.3 final release, the 1.4 release cycle, the new roadmap, the next Phoenix release, the appointment of Marcia Knous as a mozilla.org Staff Associate Member, the new Mozilla MinGW port, mail about porting fixes to 1.0 branch and reorganisation of the mozilla.org front page navigation.

> these changes shound very good, especially the point to fix blockers, not fun-features!

One person's fun-feature is another's blocker (eg look at Midas -- this is a blocker for some people embedding Gecko, apparently, so they get work done on it (by paying for said work); same applies to Calendar).

Priorities are for developers to be able to sort their bugs. Severity is a way of marking bugs as to how much they hinder daily use of the browser (both midas and the kitchen sink would have "rfe" severity, eg).

Votes can be used to push a bug from UNCONFIRMED state to NEW. That is one case where they can actually do something (although if the component is being carefully triaged, real bugs should be moved out of the UNCONFIRMED state before this happens). Other than that, the votes are just a number that displays on the bug page.

If I'm some random open source developer wants to get involved with Mozilla, or if a regular Mozilla developer is looking for some new feature to work on, votes are a good place to see where he might get the most "fame" for the fix. Voting doesn't necessarily change the project priorities but it may influence individual prioroities of individual contributors and it may influence project management in some cases.

Right now there are 10 bugs with more than 50 votes. There are over 50 fixed bugs with more than 20 votes. There are about 150 fixed bugs that currently have more than 10 votes. Keep in mind that most people move their votes when a bug gets fixed so those are bugs where the votes haven't all already been moved and which probably had many more votes before they were fixed. To repeat, most of those bugs had lots more votes before the bug got fixed. Active voters tend to move all their votes to the next bug(s) they care about once a bug has been fixed.

Votes are probably not _the_ deciding factor for anyone evaluating a bug but they can be _a_ factor. Just as a nomination for fixing a bug by a particular milestonee isn't _the_ deciding factor for drivers@mozilla.org, it is definitely _a_ deciding factor. Just as severity isn't _the_ deciding factor, etc., etc.

Lots of things are taken into consideration by the different people and groups that evaluate bugs for different reasons. Votes are payed some attention by some of the people making these evaluations. They are not "just a number that displays on the bug page."

Feel free to encourage people not to vote by telling them that votes are completely useless but know that you're misinforming them and potentially taking away one of their mechanisms for making their wishes known to drivers@mozilla.org (since I'm a driver and I watch votes) and to the developers that do now or might in the future use votes to decide which feature to add or bug to fix next. Just because you think votes don't have enough weight doesn't mean that they don't have any weight.

10 Bugs with more than 50 Votes? There are 40. And 5 of them are critical. Hwry nice one is here: http://bugzilla.mozilla.org/show_bug.cgi?id=104778 - 91 Votes, critical, "mozilla1.3", "dataloss" and "nsbeta1+" keywords - I don#t know, what else it needs to become a very important bug.

"Hwry nice one is here: http://bugzilla.mozilla.org/show_bug.cgi?id=104778 - 91 Votes, critical, 'mozilla1.3', 'dataloss' and 'nsbeta1+' keywords - I don#t know, what else it needs to become a very important bug."

The 'nsbeta1+' keyword would suggest that Netscape plan to fix it in time for their next release.

I intended to write "10 _fixed_ bugs with more than 50 votes". My point is that many bugs which have accumulated tens or even more than 100 votes do get fixed. Often voted for bugs do get fixed. They don't always get the priority it seems that voters crave.

I also failed to note something I did in my previous post on voting which is that there are 88,000+ bugzilla accounts. That means for a bug with 100 votes, approximately one tenth of one percent of the people that could have voted for the bug actually did. 0.11% isn't necessarily an indicator of much.

Flash blocking has almost 3 times as many votes as the bug you linked to. Should we implement flash blocking first? PGP for mail has more than 4 times the votes of the bug you linked to. Is it 4 times more important? Implementing x-forms has more than twice as many votes. Is it twice as important?

My point is that votes are just _one_ indicator. They are disproportionately used for features that people would like and are seldom used on issues that are genuine blockers to development and use. Votes matter. They just don't matter as much as people would like them to.

When 20%, heck, when 10% of bugzilla users vote for fixing a real bug I'll stop everything else I'm doing and work to get that bug fixed. 10% too high? How about 2%. No? Then how about 1%. When 1% of the people who have the ability to vote for a bug actually do, then I'll start to listen to those that believe votes should matter more than they currently do. Until then, votes for me will remain just _one_ useful indicator for what a very small vocal minority thinks should be fixed/implemented and not a lot more. That's not to say it's not a valuable indicator. Votes informed me that a PGP plug-in for mail was 4 times more desired by the vocal minority than a fix for your URLbar dataloss issue ;-)

Well it looks like Asa is putting the prototype together, and he's certainly heard of standards. His blog has had some pretty impressive pure CSS layouts on it in the past, and I'm pretty sure it still validates at the moment.

I didn't intend to sound negative. I just thought it would have been mentioned if the site were to be substantially redesigned to an (x)html + css basis. Instead the minutes talk about 'changing the navigation', which sounds like a more minor adjustment. Of course I'm more than happy to be proven wrong - it's a bit sad that mozilla.org doesn't display the possibilities that having a range of good, standards compliant browsers (particually gecko based browsers) on the market gives. After all, it is quite hard to persuade other people that the browser market is now mature enough to support css layout and valid, (both syntatically and semantically) code if the browser makers themselves don't use it on their main site.

Of course, I realise that all the people at mozilla.org realise this and that, originally the site needed to work under Netscape 4, and so on. My question was really that; is this change also going to fix the use of standards in the way they were intended or is it, as I suspect, a more minor alteration?

The mingw port (bug 134113) is a great thing for the mozilla project and something we should shout about when finished. Porting a massive windows app to not use MSVC is great and should be an inspiration to others. It also lowers the barriers to entry massively to no non-free software and a minimal install. Hopefully this will encourage people to download and get involved on the windows platform

somebody should explain him, what a stable version is - but I guess he's a Windows-User, and so he only knows beta-calles-stable versions and beta versions, which are so beta, that not even MS can call is different ;)

mingw builds will almost certainly be slower than the MSVC++ builds. No one is suggesting switching the mozilla.org binaries to MSVC++ (yet). But this will make it possible for people on Windows to build Mozilla without shelling out big bucks for a compiler...

I am looking for a bug in bugzilla re: the lack of help files for Controlling Junk Mail / Using Junk Mail Controls. Does it occur to anyone else that these help files really should be part of the 1.3 final release? This is a great feature which is not intuitive to use.

I am looking for a bug in bugzilla re: the lack of help files for Controlling Junk Mail / Using Junk Mail Controls. Does it occur to anyone else that these help files really should be part of the 1.3 final release? This is a great feature which is not intuitive to use.

"I am looking for a bug in bugzilla re: the lack of help files for Controlling Junk Mail / Using Junk Mail Controls. Does it occur to anyone else that these help files really should be part of the 1.3 final release?"

Based on what's happened in the past, Netscape will probably have help files ready for their next release which will then be donated to Mozilla in due course.