Possibly heretical: does the whole current backlog of changes need to
land for FF5? Even if they don't get in until FF6 (Sep 22, 2011 I
believe), that's still half the time that many of them would have been
expected in the previous release model.
risk/reward isn't something that's only for the end-game.
+1 for this particular form of heresy!
I think that preference should be given for things that:
- have proven performance wins, and benchmarks that allow us to continue to monitor them,
- have easy killswitches so we can disable them if they cause problems,
- have high demand from the web development community (ie: text-overflow:ellipsis),
But I also think that we should be taking things on mozilla-central that we know about, instead of just opening it up for any checkin.
- Patches from people who are not paid to work on this thing.
Seriously. Our story for non-employee patch contributors in the new
world so far is sad-looking. Note that I assume that employees are
working on things which are high priorities for us, so that new
contributors will by default start with things that are lower priority.
You may wish to quibble with this assumption, of course.
I think the current backlog should still be under the "normal six
week cycle" amount of changes, so I don't see the value in delaying
things to the next cycle. I could understand the argument that some
things shouldn't land *at all* because of the risk (but hopefully,
for the most part, that's not the sort of thing people are working
on) -- but I don't see why you'd suggest that they're not safe for 5
but fine for 6.
Yes, I know. What I'm saying is that we should give preference to
patches from non-employees. Your list was a list of patches to give
preference to; I suggested an addition to it.
I understand that if some random contributor shows up and writes a patch
we really want we'll take it. That's obvious. I'm saying we should
take the patch even it doesn't fall into one of the three buckets you
list it, purely because it helps us grow our community. That's assuming
we want it at all, of course; if the patch is not desirable that's a
different matter. But that gets handled at review-time.
> We'll take patches from everywhere as long as we understand the effect and the value. To imply otherwise seems odd, to me.
I'm saying that we should consider as part of the "value" of a patch
whether it helps us grow our set of contributors.
I think that's a good idea. I might go so far as to make it someone's
job on a rotating basis, like sheriffing (but over a longer period).
In my experience contributor growth comes from positive interactions in helping people understand what will help a patch get accepted and streamlining them into projects that could use their time and attention.
I know the release processes are changing, and this is probably just a
one-off for FF 5, but I think that if something gets pushed out as not
landing in the current release that is being worked on, it should be
able to be landed in the next release after that regardless of priority
Otherwise, I can see low-priority, small pieces of bug fixes, getting
forever pushed out and never landing. We also need a way to actually
flag that something has been pushed out and handle it in the next
release (rather than just rely on people using the right whiteboard
words or finding somewhere to land it).
This means patches with any of these properties, right? Does that mean
that patches which can be backed out are OK to land?
Yes, but that's the second step. The first step is for them to not get
And one other thing. We _want_ some work on things that are "not a high
priority" to happen. That's how polish issues get fixed....
Either that, or we need to change our prioritization to include things
like "make X less buggy", not just "implement Y".
I think polish issues and bugs need to be considered high priority.
> Either that, or we need to change our prioritization to include things
> like "make X less buggy", not just "implement Y".
For external contributors, at least early-stage ones, I think priorities
should be low priority.
From an external perspective, Mozilla is already a difficult project to
contribute to. Let's compare: several years ago, I wanted to use ltrace
to see into the data structures that were getting passed into library
functions. I'd never hacked on ltrace before, but I wrote a rather large
patch that screwed with some fundamental assumptions in the existing
code base. I submitted it to the project mailing list, and got back
feedback that it looked good but was breaking tests on some other
architectures, in particular ia64. I spent a weekend learning enough of
the ia64 ABI to fix it up, and used HP's TestDrive system to try it out.
Eventually, I got the test suite in no worse a shape than it was before
I started messing with things. The patch was accepted and committed.
In essence, I was able to get hacking on the code immediately, and was
willing to go to a lot of technical/development effort in order to get
my patch in. It wasn't a completely smooth nor fast process, but it was
At Mozilla, a contributor with an itch to scratch has to download a
massive wad of code, figure out MDC well enough to find and follow the
idiosyncratic build instructions, find and learn the basics of b.m.o,
and then begin researching the not-so-basics of b.m.o. and our
submission process. Contributor agreement. Reviews, and how to request
them via bmo. Discovering that a nontargeted r? will be ignored for a
decade or two, so then figuring out who to request a review from.
(Warning! People involved! Say goodbye to some proportion of technically
qualified contributors who are unwilling to engage with yet another
unfamiliar community, or too shy, or whatever.) Learn about irc, which
seems quaint to some, and our particular channels and their etiquette.
Or use blame logs, or trawl bugzilla for related bugs. Then there's
[checkin-needed], project branches, tree-watching, and starring to
That itch had better be really irritating! I never would've made it that
far. In fact, I didn't -- I had one or two ideas that I started to work
on in the Mozilla code base back then, but I didn't make it through the
Those are just the basics that we are currently willing to accept to
keep a large and complex code base under control. Now we add in
approvals, and/or a bewildering array of blocking/wanted flags. We want
these external contributors to gate their work on *our* priorities?
Contributors are volunteering to improve the Mozilla code base and
resolve an itch in something they use, and perhaps get bragging rights
and warm fuzzies in exchange. They are *not* volunteering to be Mozilla
worker bees, implementing the vision of Mozilla product managers.
Product management is enormously valuable, but I don't think it's on the
path to acquiring skilled external contributors. Even if product
management has a broad and flexible view of what changes we need, and
can describe that vision in a clear way that motivates people to work to
That's my long-winded way of agreeing with bz. External contributors
should have a greased path into the repository, and we need to be
willing to accept a fair degree of churn from low priority changes
purely to make such people happy. If we need additional barriers to
reduce destabilization or bloat, then I would propose that we try to
make those barriers technical and objective. For example, we could say
that any significant patch requires either approval *or* a comprehensive
test case. (Or evidence for lack of perf/size impact, or whatever.) The
policy should be spelled out up front as much as possible.
Anything where a contributor can work to resolve the problem
independently is fine. Anything dependent on other people is
demoralizing, because as a contributor you know that all of your hard
work can be scuttled if someone decides they don't like it (or doesn't
find it important enough on his/her priority list). Why go to the effort
if the risk is not under your control?
We don't need (more) sociopaths on the project, but we do need skilled
developers who aren't necessarily great negotiators.
Just my $0.02
So, just for kicks, I decided to figure out what a potential contributor
might have to go through to build their very own first version of
I started by Googling for "Firefox source code", and selected the first
link, because it looked nice and relevant. This was, at least for me,
if I wanted to write a patch, I probably need to use the source control
repository, which I am informed is CVS (although I am linked to
Mercurial pages for downloading). The example links use an ancient
126.96.36.199 as their base, and the prose takes a rereading for me to figure
out how to download the brand new 4.0 release.
I downloaded the 4.0 tarball, and unpack it, and notice that it unpacks
into a mozilla-2.0 directory instead of the standard firefox-4.0 that I
would have expected. Seeing that it has the standard configure file, I
run ./configure && make, and am greeted by the error that I didn't
specify --enable-application=APP. To fix this, I go back to the page,
down a few levels of links, which now tell me to get the source from
Mercurial. Assuming that the source build is still roughly the same, I
just copy-paste the links and try running it again, failing the
configure since I don't have the necko wifi headers. Trying to figure
out how to just --disable-necko-wifi takes a few more pages to find that
I need to add `ac_add_options --disable-necko-wifi' to my mozconfig.
So, just to build Firefox required looking through about 6 pages of
information, some of which is either confusing or contradictory. There's
no README in the build directory to even indicate that the build process
is much more involved than "./configure && make && make install", let
alone allow the lay user to figure out all that needs to be done.
I vividly recall my first patch. Just building a copy of Thunderbird
took around a week, although that was much due to the inadequacy of my
machine at the time as anything else (I didn't know I lacked enough
memory to build it). I think I mostly managed to figure out what needed
to be changed rather quickly, although I did require handholding to
actually make the changes. And then came the reviews. Having had enough
handholding in IRC by this point, I was told from whom to ask review;
and the reviewer actually granted the review pretty quickly. The
superreview, on the other hand... two months later, I redid a patch with
another superreviewer. When that was eventually sr+'d, I then got to do
the checkin-needed process (this was something I was already acquainted
with from another patch).
Perversely, the only reason I knew how to get my patch committed was
because I had to bear enough handholding that I became familiar with the
process by the time it got to that point. Anyone who wouldn't have
needed the handholding (my first patch ended up requiring massive
changes to underlying guts in Thunderbird code) would be lost when it
comes time to actually submit their changes. And I might add, this was
all in mailnews code, where the underlying approval levels needed are
much fewer than the current or proposed requirements for m-c (r, sr if
large enough, approval, blocking/wanted, multiple source repositories,
etc., etc., etc.). In fact, even though I do a fair amount of mailnews
work, I still don't like trying to get a patch into core Mozilla code;
what hope does a complete neophyte contributor have?
I concur with this. When I started working on SpiderMonkey, it broke
all my expectations, and I was surprised with how difficult and
frustrating it was to get started.
So I tried to fix it, by writing this:
has a good list of the sort of things developers won't understand when
they arrive at the Mozilla code base:
- what to work on
- what's happening in the code base (what are others working on)
- typical workflows
- where to find documentation
- how to get a patch actually finished!
The documentation is a particular problem: MDC is unfriendly and
bitrotten (in this area), and tries to be all things to all people,
meaning that beginners find it hard to know what info is for them and
I don't believe we have any resources allocated to this. The fact that
we don't have dashboards tracking this sort of thing seems to mean it
isn't a high priority for us. AFAIK, we don't have tools and trackers
and people who go out and say "hi, how are you, is everything OK, can
I help you get this patch in?".
It might be a good idea for those interested in fixing this to meet
during the all hands to figure something out.
I have never attempted to build any of the Mozilla apps, much less
contribute, so I can't share a war-story, but I can say that this is a
*critical* part of Mozilla's continued existence as something more than
a software company that gives away its products for free.
We joke about the "Mozilla Firehose" and the endless complexity of all
things Mozilla, but we can do so because we're familiar with them and
know how to navigate them. For someone faced with a wall of
contradictory documentation, multiple source code repositories, half a
million bugzilla bugs, dozens of IRC channels, dozens of newsgroups, a
"custom" build process, and a tortuous patch-submission process designed
to suit full-time devs, it can be impenetrable -- even for someone who
is highly motivated and willing to spend months getting through the
process the first time.
As an organization, we spend a lot of time thinking about users'
experiences, and have built a number of incredible tools to measure and
facilitate those experiences. But it seems that we assume, as
developers, that we know what it's like to be a developer new to the
project. I think this assumption is entirely invalid.
It would be good to have some metrics - both quantitative and
qualitative - about new-developer experiences with Mozilla apps. Maybe
that means some case studies, along with tracking metrics for number of
new contributors and where they drop out of the pipeline? What kinds of
itches do new developers want to scratch, and how many of those are
practical? How many want to implement features that would never be
Kudos to Joshua and Paul for their experimentation - a great start!
I know that there are good reasons for all of the roadblocks to new
contributors, and that they can't all be removed. I'm just not
convinced that measuring and reducing (or stabilizing) such roadblocks
is on the priority list.
If they are, then the task is easy: convince me :)
> On 3/22/11 3:51 PM, Joshua Cranmer wrote:
>> what hope does a complete neophyte contributor have?
I'd like to pimp my bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=616089 - Create a new contributor linux development VM appliance that is constantly kept up to date
I stick with Mozilla because I trust Mozilla source to be (mostly?)
free of outside bias, it has demonstrated cross-platform
compatibility, and is a standards-bearer. However, while I've written
my own code and submitted it a number of times (bugs 572000 and 624164
come to mind, off the top of my head), the only patch I've ever
submitted I know for sure got in the tree was a small trivial one to
fix a compile error with the mjit that Steve Fink committed on my
behalf. The rest of them are still sitting in review hell. That's,
bluntly, discouraging and Steve's post above summarizes the issues
pretty much as I would.
There are obviously people in the Mozilla team that are committed to
getting outside patches in. I would like to personally thank Boris for
his help on a couple of my bugs in the past, for example. However,
most of these I believe get downranked because they are uninteresting
to the majority or represent concerns valid only to a niche
population. If I may be so bold, that's sort of the point. If there's
an issue that's significant and has heavy-duty ramifications to the
majority of the Mozilla community, MoFo is going to put people and
money on it already. For the rest of us with an "itch to scratch," the
review system, while no doubt helping to keep the core stable, is also
a huge barrier to entry. Documentation is its own issue, but that's a
solvable problem. Reviews are hard because it's arbitrary and r+ may
entirely depend on whom you ask.
Much is made and said of "no free lunch," and I obviously understand
the rationale of the policy. However, for niche features, even if we
want to step up and work on them, no one is interested in taking them
(bug 572000). The usual counterargument to this is the cost of
supporting a niche feature. Well, frankly, if Mozilla wants to
encourage outside developers, that's a cost that you'll have to accept
to a certain level because outside core developers, niche is what
you're going to get (the low-hanging marquee features already have
devs on them). If the watchword is "we only want features we think
matter," then you're going to get a correspondingly smaller pool.
Take bug 621175, for example. The patches for 10.4 aren't wanted, and
I can understand why, even if I don't like that either. But even for
NPOTB patches, even working with a small group such as Adobe to get
the PPC nanojit in, it drags on and on. Fortunately I know exactly
where my r is eventually coming from (Rick) and an sr is probably
easier given it is NPOTB. But that's just luck and it was only because
Edwin Smith helped me out that I know where to go.
Now that I maintain my own browser forks, my checkin process is easy
because I accept the patches I want to accept in my own little
fiefdoms. I donate back the work I think is of community interest
where and when I have the time, but (and I hate to say this) whether
it gets in the tree or not is no longer something I particularly care
about, because odds are it probably won't. I believe in open source,
and I believe in giving back, which is why I still do it as time
permits. I would like to contribute more, but it's a discouraging
process when the likelihood of it actually reaching a point of benefit
My two cents.
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]
On Wed, Mar 23, 2011 at 10:48 AM, Dustin J. Mitchell <dus...@mozilla.com>wrote:
> For someone faced with a wall of
> contradictory documentation,
Some obsolete stuff should be updated or removed, definitely.
> multiple source code repositories,
You only need http://hg.mozilla.org/mozilla-central to build Firefox.
half a million bugzilla bugs,
The total number of Bugzilla bugs is not really relevant to a new
dozens of IRC channels
The IRC channels are a feature. If someone finds #developers they are very
likely to get all the help they need on that channel. If they're asking dev
questions on the wrong channel, someone should be redirecting them. I do not
see lost developers on IRC.
dozens of newsgroups
We should reduce them, but a new contributor does not need to know about
> a "custom" build process
It's autoconf and make. It's really not very custom.
> and a tortuous patch-submission process designed
> to suit full-time devs
I'm not sure that it's particularly suited to full-time developers. The
process hasn't really changed since "super-review" first appeared in
2000-ish, which includes a period when there were hardly any full-time devs.
For a new contributor, one hard part of submitting a patch is knowing to
request review, and knowing who to request it from. Perhaps someone could do
a daily sweep of bugs with patches requesting review from nobody? The other
hard part of submitting a patch is when reviewers don't do timely reviews.
This is simply a matter of reviewers being conscientious. Perhaps another
periodic crack of the whip is in order. One workaround for both of those
problems is simply to contact certain people for help. Boris or I would do,
or #developers. That should be documented somewhere.
It would be good to have some metrics - both quantitative and
> qualitative - about new-developer experiences with Mozilla apps. Maybe
> that means some case studies, along with tracking metrics for number of
> new contributors and where they drop out of the pipeline? What kinds of
> itches do new developers want to scratch, and how many of those are
> practical? How many want to implement features that would never be
Updating MDC --- especially, removing or fixing obsolete information --- is
probably the most productive thing anyone can do right now. And fortunately,
anyone can do it!
Indeed. None of your responses are incorrect, but I suspect my post
captured the newcomer's perspective. Unknowns are big and scary!
> For a new contributor, one hard part of submitting a patch is knowing to
> request review, and knowing who to request it from.
Without meaning to pick on you specifically, what evidence do you have
for that assertion? (Well, I suppose "one hard part" is easily defended
- but do you know whether this is one of the five hardest parts? How?
What are the other top four hard parts?)
> Updating MDC --- especially, removing or fixing obsolete information ---
> is probably the most productive thing anyone can do right now. And
> fortunately, anyone can do it!
I don't disagree with you, but arguing "it's not that bad" is, IMHO, a
risky strategy when anecdotal evidence points to a very steep learning
curve (and a high mortality rate) for new contributors.
So, in short, I think that the new developer's perspective is missing in
the development-planning conversations since December, and that to avoid
our own biases we should be applying formal techniques to learn about
that perspective -- just like we do for novice *users* of our apps.
> > For a new contributor, one hard part of submitting a patch is knowing to
> > request review, and knowing who to request it from.
> Without meaning to pick on you specifically, what evidence do you have
> for that assertion?
Observing many examples of people requesting "r? from the wind" in bugs, or
attaching a patch and failing to request review.
Although the cases I see are usually quickly corrected by someone watching
the bug (usually not me). So maybe it isn't a huge problem overall. Depends
on how many bugs get patches but are not watched by anyone who knows the
So, in short, I think that the new developer's perspective is missing in
> the development-planning conversations since December,
Those conversations have almost entirely been about how to get reviewed
patches landed, which is mostly orthogonal to the issues you raised. Boris,
myself and others have expressed the necessity for making it easy for
miscellaneous contributor patches to land in a timely manner.
and that to avoid
> our own biases we should be applying formal techniques to learn about
> that perspective -- just like we do for novice *users* of our apps.
Maybe, although developers are less important than users. It would be a
really interesting project though; not only would it help Mozilla, it would
shed light on open source software development in general. Dave Humphrey
probably has something to say about this.
Still, if you want to make a positive contribution, please edit MDC :-).
> Still, if you want to make a positive contribution, please edit MDC :-).
Er, that sounded rude. Sorry.
I meant to say that editing the obsolete pages in MDC that appear high in
Google results is still the most positive contribution anyone can make right
My experience has been that Mozilla's complexity is only ever dealt with
through relationships vs. resources. You can't write your way out of
this problem, since there is already too much written. Instead, I think
it's important to actively look for ways to help new people personally
via irc, bugs, etc.
Some of our developers are amazing at this. People like bz, shaver,
ted, jorendorff, gavin, joe, the list goes on, and I won't attempt to
name them all for fear of missing people. Watch them on irc, and in
bugs, and you'll see what I mean.
I really believe that more of us should be proactive in bugs to advocate
for people, defend them against unnecessary attacks or pedantic crap,
buffer them through irc channels, and above all encourage them. Most of
us can take getting banged around, when we are secure in our position
within the community; it's not the same for someone new.
There are enough of us who care about this that if we each do a bit to
help guide people through the maze, it isn't that much work. I've
brought hundreds of students into Mozilla, many of whom weren't your
typical Mozilla dev, and most survive and thrive. Mozilla is huge,
complicated, and hard, but with friends and mentors around, it is
manageable, even for beginners.
I think we can unwrite ourselves out of it, to an extent. That is to
say, removing obsolete documentation.
> Instead, I think
> it's important to actively look for ways to help new people personally
> via irc, bugs, etc.
I think this is true, but it does have a certain amount of difficulty
scaling. We should try and reserve the time of the people you name below:
> Some of our developers are amazing at this. People like bz, shaver, ted,
> jorendorff, gavin, joe, the list goes on, and I won't attempt to name
> them all for fear of missing people.
...for filling in the gaps which can't be filled by documentation (e.g.
doing reviews and super-reviews).
> I really believe that more of us should be proactive in bugs to advocate
> for people, defend them against unnecessary attacks or pedantic crap,
> buffer them through irc channels, and above all encourage them.
Quick plug: if anyone sees someone handing out the attacks in Bugzilla,
contact me or another b.m.o. admin and we will take action.
I entirely agree that the fact that a patch was written by a volunteer
should be considered a point in favour of prioritizing it, in the same
way that it being a performance win would, or it being in high demand
from the webdev community. That is an awesome idea.
There is a risk that the new development system will lead to everyone
being even more stressed and busy all the time than they are now,
because we will always be close to a release. How can we make sure
existing core community members are able to invest time in tomorrow's
core community members?
I think that a '20% time' thing for Mozilla employees would be awesome -
every Mozilla employee must spend one day a week looking for,
encouraging, reviewing the patches of, discussing things with or
generally involving people who are not employed.
(Some people, of course, will be above 20% already.)
I have tons of practical experience with this in l10n land.
The sentence "attach your patch and request review" is full of jargon,
basically. It implies all of:
make a patch (diff, review the diff yourself, diff to file, kdiff for
you instead? oh, nifty)
create an attachment in bugzilla, mark it as patch
find the 'review' flag, and map "request review" to setting the drop
down next to it to "?"
entering a bugzilla ID as requestee (which is already a word that
non-native speakers probably have issues with wrt English skills)
I see people fail often on this, in particular in l10n land, and I
assume that newcomers are on a similar level when it comes down to FLOSS
and bugzilla jargon.
On 3/23/11 12:25 AM, Robert O'Callahan wrote:
> On Wed, Mar 23, 2011 at 6:23 PM, Robert O'Callahan<rob...@ocallahan.org>wrote:
>> Still, if you want to make a positive contribution, please edit MDC :-).
> Er, that sounded rude. Sorry.
> I meant to say that editing the obsolete pages in MDC that appear high in
> Google results is still the most positive contribution anyone can make right
> now. IMHO.
More specifically, ways that you can help improve MDC:
* If you find a page that is outdated, and you know what info to update
it with, please do so.
* If you find a page that is outdated, and you don't know how to update
it, or don't have time, tag it with "NeedsTechnicalReview", and add a
comment to the corresponding Talk page describing what is needed.
* If you find a page that is too out of date to salvage, tag it with
"Obsolete" (with a Talk page comment if possible). This lets the wiki
admins know that it should be archived, or at least flagged with a big
fat "Obsolete" banner.
I have come across pages where it is very difficult to know what to
do, and where I am not able to answer these questions:
- Is this page obsolete?
- What should happen with the sorta-old info on it?
- Is the advanced information on this page useful or in the way?
- Is the organization of this set of pages
- Should I add information which already exists elsewhere (but perhaps
in a different form)?
- If I fix the page organization for some subgroup (lets say
beginners), do I ruin it for some other group (perhaps non-beginners).
I've had this same problem at least three times, and each time
retreated in confusion.
To be honest, I don't think we're dealing with this in the right way.
We wouldn't ask people with a casual understanding of the code base to
commit "fixes", or have numerous developers working on the same code
without communicating, and without a shared vision for the end result.
I think we lack a set of principles by which to update MDC, for
- how should information be arranged so that it can benefit both
beginners and advanced users?
- how can we gauge the "right way" to add information to a page?
- is there an owner we can contact for guidance?
- how do we communicate with others who are interested in the same information?
... that got them quickly up to speed on the project and how to work
in the Mozilla system. Though not perfect, it certainly helped.
Yes. I found the required use of a mozconfig to be an obstacle, esp.
since no two people seem to have the same mozconfig. And then you
can't just do "make" but have to do "make -f client.mk build" or
similar. (Maybe you can do something different and/or better now, but
that's the magic incantation I embedded in my wrapper script two years
ago after some trial and error.)
> Yes. I found the required use of a mozconfig to be an obstacle, esp.
> since no two people seem to have the same mozconfig. And then you
> can't just do "make" but have to do "make -f client.mk build" or
> similar. (Maybe you can do something different and/or better now, but
> that's the magic incantation I embedded in my wrapper script two years
> ago after some trial and error.)
I assume you hadn't found
If so, that confirms we just need to unwrite ourselves some documentation to
make sure that page is the first hit for the appropriate searches :-).
I agree that more communication about these issues would be good.
The mailing list for MDC is https://lists.mozilla.org/listinfo/dev-mdc
How about starting a thread there about how to structure information for
new Mozilla developers?
IRC discussions for MDC take place in #devmo. During US business hours,
Sheppy and I are usually there. We have contributors in Europe and
Australia who are fairly knowledgeable about the site and may be online
at other hours. However, they may decline to give strategic/IA advice.
(BTW, we have a community meeting for MDC contributors in #devmo at
10:00am PT on alternate Wednesdays; the next one is on March 30.)
In the bigger picture, I think it would be awesome to apply some of
Mozilla's user experience brainpower to the total experience of new
contributors (not just docs, but the whole process of getting involved).
I believe David Boswell and the Contributor Engagement team are working
on some aspects of this, but the groups that interact with contributors
(dev, QA, l10n, etc.) are the experts on their own processes.
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
> That's my long-winded way of agreeing with bz. External contributors
> should have a greased path into the repository,
I'm not picking on you (praise be to you and others in this thread
trying to make things better,) but you're an easy hook for this request.
Can we please stop referring to people not paid by Mozilla as
"external"? Mozilla (the company) is a contributor to the Mozilla
project. Yes, it's a huge contributor but it is still a contributor, and
the not-paid-by-Mozilla contributors are just as internal to the project
as are those who are paid by Mozilla. There is no internal and external
The same goes for the phrase "the community". Mozilla (the company) is a
part of the Mozilla community. It's a big part, but it is not a separate
thing from the community.
If you're looking for a good word to describe a person or group of
people not paid by Mozilla, please try some of these on for size:
volunteers, volunteer contributors, community volunteers, Mozilla
I can't remember the exact steps I went through, but I did see and
follow this page. The mozconfig and non-standard make invocation was
still strange; I was expecting a simpler configure+make experience.
Also, it doesn't take long before that simple mozconfig isn't enough
-- it doesn't enable tests, it doesn't allow for 32-bit builds on
64-bit machines, etc, etc. No real developer has a mozconfig that
Not to nit-pick you, but we have been striving over the past few years
to make the default configuration as close to what we ship as
possible. The default configuration does enable tests, builds an
optimized build, and just about everything else that we can do without
special requirements. I've been thinking about making
--enable-application default to "browser" as well, so that "configure
&& make" would work out-of-the-box.
On Mac my mozconfig contains exactly --enable-application=browser --
it builds tests and everything else. Sometimes I have
"--enable-profiling --enable-optimize" there for specific tasks.
Often I don't even bother with a mozconfig and just run configure by
hand. We should probably make --enable-application default to
browser, since that's by far the dominant use, but if we gave the
"need enable-application" error message right away rather than after 2
mins of configure that might suffice.
On Windows I disable angle and a11y because I don't have the SDKs.
Following the full build instructions obviates that, though. (I also
use pymake on Windows, but that's an optimization due to gmake's awful
performance under msys.)
Cross-compiling is advanced magic on every project I've worked on that
had any meaningful system-specific code, or tools built in the
process. Don't get me started on crossing glibc or the kernel. It's
hard on the Mac IIRC because Apple doesn't provide gcc-$target for the
32-bit stuff, so you have to dork around with all the various CFLAGS.
Most of the complexity in the build instructions are due to:
- still having text about building old branches, which I think we
should immediately move to "old stuff" pages (I'm volunteering)
- needing autoconf-2.13 because of the incompatibility; I forget what
we use that modern autoconf doesn't provide, but it was non-trivial
- having all the instructions about which SDKs to download, how to get
stuff from Macports, etc. We should streamline these too.
The instructions are a little more compleatist than is probably
helpful. They're a little "well, actually..." and not really focused
on what new developers want: the shortest path to a firefox binary
they can start up. But the build system itself doesn't have to be
very complex at all.
On the mozilla.org/contribute pages we've been experimenting with ways
to help people interested in getting involved with Mozilla become
One thing we've done is to invite people to contact us if they have
questions about how to contribute. This means we regularly get emails
"I want to help work on firefox but I have never contributed to OSS
before. The whole project is a little daunting though, I could use a
little help getting started (little bug fixes, documentation, whatever
About 100 people have been contacting us through that page each week.
Based on best practices from other non-profits, if we're performing
well then 1 out of 10 of those people should be expected to become
We don't have great metrics here yet so we don't know how successful
we've been, but it doesn't feel like we've added 10 new active
contributors to the project each week over the last year and a half.
I'd be very happy to work with people here to do a number of things
mentioned in this thread:
* Create easy to understand getting started information and good
initial project ideas to send to people who ask questions like the one
* Create a group of mentors to help and encourage people who are
expressing interest in contributing.
* Create a better way to determine what is working and what isn't
working in the process of bringing in new active contributors.
Looking forward to talking more in this thread and in person. The new
#mozillians channel on IRC is also a good place to discuss ideas about
how to help new people become active contributors.
Well, not so sure that's "perversely". Any such large code-base probably
needs some hand-holding until you get how to deal with it (try the Linux
kernel or Wine and you'll probably also need some time to get started).
The reason why the SeaMonkey project is - for its rather small volume in
users - reasonably effective in getting contributors that help with code
(even though review can sometimes be a hard step in that project) is
that people spend a lot of time on IRC and do a lot of hand-holding to
get people acquainted, to make them feel good in the project.
I experienced a lot of that in the L10n community when I came into the
Mozilla project, which encouraged me to get more and more involved, and
I always tried to communicate a lot with people who are interested in
seeing something changed, esp. if they seem to be willing to take action
IMHO, we should find some way to encourage Mozilla employees do that
without making us be less productive overall (I'd think that serving as
a multiplier, it should actually make us more productive), and I think
Gerv's "20% time" idea posted earlier in this group could be one
possibility to try and improve this.
We surely should try and improve documentation and think about how we
could make the whole process of contribution easier, but from my POV,
the most important part is that we need to actively communicate with
interested people and do some hand-holding on their first steps into the
When (I think we can, so it's a "when", not an "if") we manage that, we
already achieve a lot.
I think it's great we give them this possibility. What we need to try
hard to do is to reply back to them and give them some pointers (which
we need to have available, of course) to the specific areas they are
asking about, or at least who to connect with on that area.
And yes, there needs to be personal contact, not just docs. People want
to feel they are part of the community when they are contributing, so
personal contact is very important. We're a community of humans, not of
web servers (well, probably a bit of both *g*).
What, specifically, is the response to this?
I think the relevant partition in this discussion is "external"
meaning "not from someone already close to the project": people who
don't know who to ask for help, how to navigate bugzilla, etc. F.e.,
I would consider philor to be "internal", and from a
getting-a-patch-done perspective I would count many of our
non-developer employees. (Such employees have lamented the
difficulty, in fact!)
> On Wed, Mar 23, 2011 at 5:33 PM, davidwboswell <davidw...@yahoo.com>
> > "I want to help work on firefox but I have never contributed to OSS
> > before. The whole project is a little daunting though, I could use a
> > little help getting started (little bug fixes, documentation, whatever
> > you need)."
> What, specifically, is the response to this?
GNOME has a GNOME Love project. In addition to a mailing list and IRC
channel, bugs that are easy for beginners to tackle are marked as GNOME Love
I know several professors that ask their students to find and solve GNOME
Love bugs as a way to get started.
Another idea would be to hold a time at conferences where people could bring
their laptops and get help setting up their build environments.
What do you say to them?
> * Create easy to understand getting started information and good
> initial project ideas to send to people who ask questions like the one
For code work we have some of this (good first bug annotations and the
simple build instructions). For other things, I'm not sure...
> * Create a group of mentors to help and encourage people who are
> expressing interest in contributing.
I think it shouldn't be hard to find volunteers here. Count me in.
Both the gnome-love and gnome-women projects are ones that I would
love to see us emulate. I don't know if that falls into dboswell's
current scope or if it needs more thrust.
OK. I misread some of this thread and was thinking it was about people
already in the system but working on things that Mozilla leadership
doesn't put high value on and so were at risk of having their patches
rot and that that might get worse in a shorter release cycle with
People that can't get their stuff it are by definition on the outside,
I think, and we should strive to bring them in. Employees will be
working on things that don't make the cut, but I don't think the rot
risk goes up, since it's proportionate to change rate, and that
shouldn't be affected much by the new system.
For this inquiry, I sent this person the following response:
I maintain a wiki page of responses to common inquiries and then edit
that as needed if people ask specific questions about a given topic.
One thing that would be helpful to get from this thread is an improved
response to people interested in getting involved in coding (or any
other project areas people have useful getting started information
for). Feel free to edit the wiki or send me suggestions.
Getting the response right is important, but I also think the act of
responding and making a connection is far more important than the
content of the response. Even if we had perfect documentation that
people could find or be sent, we'd still want a way to let people get
their foot in the door in terms of meeting other Mozillians.
> > * Create a group of mentors to help and encourage people who are
> > expressing interest in contributing.
> I think it shouldn't be hard to find volunteers here. Count me in.
That's great. Thanks for that.
Right now the system we have for bringing in inquiries and handling
responses is a hack. I quickly put a 0.1 version of this contributor
input process together to see what would happen and we'll work to
improve that this year.
I'd be happy to walk you, or anyone else, through the current kludgy
system or I can get back to you when a more useful system is in place.
I would consider myself very much in this "external" group.
I have (or rather, had ) commit access. Nonetheless, trying to do
anything useful is harder than pulling teeth, because 1) I'm never
working on Firefox directly, meaning 2) module peers/reviewers are
always either working on whatever new feature (pre-beta) or the next
blocker (beta+) instead of my patch, and 3) it typically doesn't make
sense for me to work during ZST workweek (because I have an actual job
to do), so asking anything in IRC when I do have time - at times roughly
approaching midnight - usually leads to dead silence. Checking in
doesn't work either, since that's something like 6 hours when I tried (a
long time back, actually), and due to the above time zone problems, no
real way to figure out which particular known orange something is.
Essentially, posting patches feels more like throwing it over a wall,
since I can't expect a response in any useful time frame. I don't
_want_ this to be the case, but there really isn't much I can do about
it. (In terms of the no free lunch analogy: the lunch lady refuses to
take my money, something about my money not being company-issued.)
At least I managed to get past the "building something" stage back in
the cygwin days... I'm probably not your typical case, though; going by
MozillaZine posts, I started building eight years ago.
I've been following the whole release + new plan thing for a while now;
just have been keeping silent because, while having this discussion
about bring in more contributors is nice, I feel nothing will change
until the people in charge -- drivers, (MoCo) management (since they
drive Firefox and the resource behind it), shaver/gerv/mitchell in their
"the buck stops here" capacities -- decide they want it, this will just
go exactly where the previous calls for participation go. My goals are
about making Mozilla awesome, not about making Firefox awesome, even
though there's large amounts of overlap.
If there's a public declaration of sinking more resources into getting
external (there's that word again!) patches in, and a little bit more
highlight on successful instances of it happening, I'd be quite happy to
sink more time in. At this point, however, I mainly just post patches
of things I have because I like to share, not because I have any hopes
 L3; my account got disabled because I hadn't checked in anything -
because I found the requirement to run the full test suite locally
prohibitive (a clean build fails tests the last time I tried). There
was no notification.
There's no such requirement. If something says there is, we should
That said, you should run the tests that you feel are appropriate,
and use https://wiki.mozilla.org/Build:TryServer as appropriate for
additional testing on the real infrastructure. If your definition
of "as appropriate" turns out to be off, we expect you to learn from
your mistakes. If you don't, people will tell you to be more
careful. (In theory, in extreme cases, we could revoke somebody's
access for breaking the tree too often, but I don't think we've ever
FWIW, except for --enable-application=browser, you can very much have a
"normal" configure + make experience, provided you use the source
tarballs. With the source coming from mercurial, you only need to first
run autoconf2.13 in the main directory as well as in js/src, and then
you're back to "normal" configure + make.
client.mk is only a facility. And when you have a lot of ac_add_options,
it's just simpler to use client.mk + mozconfig than to build a configure
command each time. But newcomers don't need to know that.
Actually, I think the Simple Firefox build page should just say
- ./configure --enable-application=browser (and remove
--enable-application=browser when we make it the default)
Then point to the more subtle variant:
- mkdir objdir
- cd objdir
- ../configure --enable-application=browser
And only then talk about mozconfig and client.mk, possibly even on a
I think the best thing we can do with these inquiries is to refer them
one-on-one to people that have been around a while and can point them in the
right direction and answer questions.
The trouble with "volunteers" or related words is that it makes a
distinction between those who are paid and those who are not, and I
don't think that's a good distinction to major on.
Also, there are people paid to work on Mozilla (i.e. not volunteers) who
are not paid by Mozilla. Bob Relyea at Red Hat is one such.
I actually prefer the "community" language, but I agree it's not perfect
either, for the reasons you give.
(I think this is an important discussion, not a bikeshedding point.)
What David said, and also: getting your account re-enabled should be as
easy as filing an IT bug and waiting a few hours - or less, if you ping
them on IRC. If it's harder than that, tell me.
What David said, and also: getting your account re-enabled should be as