I like the idea as well, it allows every developer out there to find a project related to Mozilla they can help with. Too bad it ends up very quickly on a hard to read Wiki page (I have never liked those).

[1] https://careers.mozilla.org/en-US/

I know that many open source projects have difficulties attracting them, but I really don't know the reasons (any reason designers working in this field gave me also should apply to programmers - thus they also couldn't answer this question).

2) Testing. Good UI and UX need to go through several rounds of highly controlled testing. The "controlled" part is the factor here--a group of guys in the basement isn't going to cut it, and there's no way to verify with open source communities that testing was done correctly.

3) Consistency. Design teams are able to churn out more consistent work once they've found their 'style'; multiple disparate designers are more likely to break that style.

4) Preventing design by committee. Pull request discussions for design changes could turn into disastrous free-for-alls that end up turning Firefox's chrome neon blue and each button red because the majority of random devs think it's 'cool'. Design is more successful as a dictatorship than a democracy.

Concerning point 3:

"Probably the most daunting question for projects without any design lead that has the trust of the team is, how do the devs know if the proposed design is correct? Without that trust, bugs quickly devolve into nasty arguments. How you build that trust has been the subject of entire books. But the question remains, who and how do you approve a mockup? The code review process works great for just that… code."

Developers also have nasty arguments about what code is correct/the better one etc. ;-)

So this argument also should in principle apply to developers - but developers don't seem to have any problem about that point. I don't know whether the reason is simply that developers have less a problem with conflicts?

But nevertheless: there are well-established principles to judge which code/software architecture is better (elegance, smallness, extendability etc. (all of these can be judged rather objectively) - which role these play, depends on the project). I think it would help project leaders if you suggested a similar process for judging design decisions. Just an idea. If this is a bad idea of me, suggest a better one.

You're implying a value judgement that code is an objective discipline and design in a subjective discipline. There are aspects of visual design that are subjective. However, UX is a testable, repeatable, objective discipline that is informed by the work of cognitive science.

Yes coders have arguments... with coders. They have inside baseball arguments. It's entirely different than a designer having an argument with a coder. Often, the designer has to teach the coder the principles of design in order to even engage in a logical, productive discussion.

The overriding point I was making is that the tools like github are designed for code, not design. Our tooling inherently advantages code. It's a pain in the ass to even insert an inline image into a comment. Github isn't built for evaluating mockups and wireframes. Designers do our best to bootstrap into the tool, yes. But it's not our tool.

One of the challenges of design education for developers is that developers are naturally geared toward rule sets, which becomes a problem when the designer decides to break the rules for a justifiable reason. Just like devs couldn't teach a designer to code in a day, a designer can't really provide all of the ins-and-outs of good design to devs. Perhaps education needs to be introduced to devs as to the value of UI/UX, rather than the specifics.

If so, you can hunt down whether it's an extension (likely), plugin, or some config setting that's causing issues.

e: Ok, so it's the delicious addon. Surprised that no one caught that in the 12 weeks of aurora/beta builds.

"Oh, you're a C programmer? You can work on NSS".

Thanks for letting me know. I'll log that away. How about this:

"You're a C programmer? Here's an interesting bug targeted to the NSS component I've pulled from Mozilla's bug database which might catch your fancy"

Hm, that's interesting. How would I solve that? Maybe if I...no. Hm. Let me pull down the source code to see what would work here...

http://flyinformation.nfshost.com/bugsahoy/?cpp=1

C++: "So you like long compile times and incomprehensible error messages? That's cool, we do too"

Java: "So you're a believer in AbstractMethodFactoryBeans? That's cool, we all have our vices"

Python: "So you enjoy the paradigm of backtrace-driven development? That's cool, everyone gets a bit tired of static typing once in a while"

C: "So you think OOP is for hipsters? That's cool, we all get nostalgic sometimes"

Javascript: "So you're a dynamic individual who thinks that, underneath, everything is an object? That's cool, we like to dream as well"

For Rust, it just sends you directly to it's site.

Criticizing languages/paradigms is fine (the resulting flame-wars add a great deal of humour and interest to the world of programming) - but to caricaturize users of different languages as people suffering from certain negative traits is just ugly and leaves me with a bad taste in my mouth reading this.

I for one would not want anything further to do with this author or site.

YOU CAN'T TAKE A JOKE.

I'm still waiting for it to stabilize, but I plan to experiment with Rust in my next systems-level project.

The page assumes that they only need programmers. If you don't know any languages and are not interested in learning, you can help in other ways like on mozillazine and irc. Artwork, etc etc. It may be good to work through how the buttons/layout should work for this, but overall I think you'd get more involvement in that fashion.

Other than that, I think this is pretty neat. I may copy it.

[0] http://www.mozilla.org/en-US/contribute/

Every project can do with documentation help etc.

...but it gets you right to bugs, which may be a harder place to start for some contributors.

I debugged it for you - the outerHTML property isn't supported in Firefox < 11. Here's the solution from StackOverflow:

function outerHTML(node){ return node.outerHTML || ( function(n){ var div = document.createElement('div'), h; div.appendChild( n.cloneNode(true) ); h = div.innerHTML; div = null; return h; })(node); }

This should be in every Django book!

I'll admit I've never contributed to FOSS so maybe a veteran can fill me in but I see this a lot with projects. Some have decent issue/bug tracking, but I often find it very difficult to determine how a project is supposed to progress, what features are needed for the next release, where do they stand currently, etc. I assume a lot is decided out-of-band through e-mails and IRC.

If you want to contribute to a Mozilla project, but can't figure out how you can help, please come on irc (irc.mozilla.org), usually on #nameoftheproject (here #shumway), or in #introduction if you want something more generic.

Some of their web projects have amazing documentation for new contributors, such as Kitsune's documentation: http://kitsune.readthedocs.org/

This site definetly did a good job of directing me in the right direction. Its a good idea IMO.

Also, it's shared with other projects (Google uses it).