doesn't really seem relevant to Hacker News

Is anyone else reminded of 3M by this? Also, Apple had Steve Jobs leave, company founder, then Jobs returned & Apple was swell. Similar situation. Maybe it's the grandpa in me but I feel like one gets a sense of that 'CEO feeling' at any company.. that is is why they're called the CEO.

speaking from a similar perspective here, I'm jealous of your long list of contributors

Piggybacking off of this, if anyone would like to try their hand at contributing to Servo I recommend checking out the "E-Easy" bugs on the issue tracker ( https://github.com/servo/servo/labels/E-easy ) and hitting up #servo on irc.mozilla.org ( http://chat.mibbit.com/?server=irc.mozilla.org&channel=%23se... ). It's not often that you get to be a part of rewriting a browser engine from scratch. :)

And you don't need to be a Rust expert to contribute (not least because essentially nobody in the world fits that description)! It's totally common for initial commits to be the first serious lines of Rust a contributor has ever written ( https://twitter.com/chimeracoder/status/583755185899626496 ).

I think this is a great advantage of Rust. Even with code review, you won't want to contribute your first C++ code to WebKit. But it's totally possible to contribute your first Rust code to Servo (I witnessed this multiple times), and damage you can cause is quite limited.

WebKit actually has quite a lot of fairly nice, simple easy-to-read C++, especially around the DOM. Or at least did a few years ago, and I believe it's still mostly the case.

I remember asking for advice years ago where to cut my teeth on C++ and getting suggested WebKit by several — and people who weren't trying to lead me massively into a pit of doom. (Admittedly, I've still practically never contributed to WebKit, and I ended up doing my first larger bits of C++ on Presto. But hey, I've still read plenty of WebKit code over the years.)

One nice—and, I think, underappreciated—thing about Servo layout is that the parallelism forces you to organize your algorithms cleanly. Unlike every other engine, render objects in Servo are not responsible for laying out their children recursively; the higher-level parallel traversal driver does that. That means that you must write your layout code in such a way that the right information is available at the time the traversal invokes your layout method. You are also limited in what you can access: your render object can't access your parent (because that would be racy), nor can it access the DOM (because we can run layout off the main thread). This requires a fair bit of up-front thought, but once that's finished it's easy to read the resulting code, because the layout code is grouped into specific functions ("assign-inline-sizes", "assign-block-sizes", and so forth) that do just one thing. This goes a long way toward making layout easier to understand, especially when it comes to complex situations like tables.

Right — and it's hardly surprising that Servo's codebase is in many ways nicer than existing browsers (both because of the inherent separation parallelization causes, and the lessons learnt from existing browsers). And given layout has always been arguably the worst part, it's hardly surprising that Servo shows good gains there.

Note that the contributors are from a period of three weeks (due to other commitments I ended up postponing/procrastinating this blog post for two weeks). But yeah, we usually get a lot of new contributors -- around 4 a week, with around ... 20% retention? (mostly guessing from observations). Still pretty nice given our size.

I'll attribute this to a couple of things:

We actively maintain a list of [easy bugs](https://github.com/servo/servo/labels/E-easy). This also means holding off on fixing minor things. For example, if I'm working on a feature I might notice some things which can be fixed, or have some portions of the feature that are easy to implement but can be excluded from the main pull request without losing out on much. I'll file E-Easy issues and land the basic pr, and those small changes will be something a hopeful new contributor can pick up and work on. Resisting that itch to fix all the things gets us a good crop of easy bugs. We don't have many string substitution easy bugs[1] unlike projects like Firefox, but most of the easy bugs can be worked on in an hour or two given a Servo build and basic Rust knowledge. Usually less than that.

Additionally, we do easy bugs right. There's almost always enough information to help a newbie get started; with links to the relevant code and/or spec. Of course, there's a lot we can improve on here, but we're still ahead of the curve on this.

We also mentor newbies -- if you leave a comment on an issue asking for help (or drop in on IRC), someone's bound to help you.

We consciously consider newbie onboarding, too -- "will this affect newbies?" is a common issue that springs up in discussions. It helps that many of the core contributors (including me) are volunteers themselves.

Our code generally isn't too complicated. Most of the areas which newbies flock to (eg the DOM) are well documented and we don't have much usage of advanced, confusing looking Rust features. I've seen open source code heavy with template metaprogramming and all sorts of strange macros --- whilst our code does use macros and syntax extensions, it looks pretty clean and to the most part the strangeness is innocuous (eg the annotations and other strangeness look ignorable). To be fair, this is probably highly subjective, but to me Rust code is generally quite readable, even when it uses advanced features -- it was this way when I started, too.

Also, we have Josh[2] :) He is behind most of the mentoring system in Firefox and is in general very interested in easing the way for new contributors -- most of the stuff above probably was largely his initiative. If you want ideas on how to improve newbie onboarding on a project you're interesting, you might want to have a discussion with him (or Ms2ger) in IRC.

[1]: I'm really fond of such bugs because they make for a very smooth transition for those trying out open source. For the first bug you do some easy thing like editing a string or deleting a comment or renaming a function, and get used to the version control system, issue tracker, and the workflow. For the second bug, try something more substantial; you can focus on the code this time without worrying about other things. [2]: http://github.com/jdm

It's a MVC (Model-View-Controller) web framework made in Python that works with a number of different kinds of databases.

Check out the models overview to get a feel for how powerful and simple it can be to use: https://docs.djangoproject.com/en/1.8/topics/db/models/

Actually a MTV framework https://docs.djangoproject.com/en/1.8/faq/general/#django-ap...

Strictly speaking it's a MTV framework (like all traditional web frameworks really).

But half the time people use it as a MVC framework where URL's act as the final link back to the model.

Fine, I'll see your negative karma and raise you the heading from the site:

Django makes it easier to build better Web apps more quickly and with less code.

You either see (call) a bet or you raise it, you don't see and raise, as it's confusing. There's a name for this confusing, inappropriate behavior in a poker game: string bet [0], and it's simply not allowed at most tables.

[0] http://www.pokertips.org/glossary/w/STRING+BET

its a pretty popular web framework for python.

It's worth it to get an education but you have to MAKE IT worth it

applying this to my list of 'interesting techie things'

Arnie sells watches, Apple sells watches, now Tag Heuer.. EVERYONE IS SELLING watches!!! Jeez talk about a bunch of sheeple! Maybe I should start selling watches.