11 Feb 2026

feedPlanet Mozilla

Thunderbird Blog: Thunderbird Monthly Development Digest: February 2026

Welcome back to the Thunderbird blog and the first post of 2026! We're rested, recharged, and ready to keep our community updated on all of our progress on the desktop and mobile clients and with Thunderbird Pro!

Hello again from the Thunderbird development team! After a restful and reflective break over the December holidays, the team returned recharged and ready to take on the mountain of priorities ahead.

To everyone we met during the recent FOSDEM weekend, thank you! The conversations, encouragement, and thoughtful feedback you shared were genuinely energizing, and many of your insights are already helping us better understand the real-world challenges you're facing. The timing couldn't have been better, as FOSDEM provided a strong early-year boost of inspiration, collaboration, and perspective.

FOSDEM - Collaboration, learning and real conversations

This year, a larger contingent of the Thunderbird team joined our Mozilla colleagues in Brussels for an intense and rewarding FOSDEM weekend. Across talks, hallway chats, and long discussions at the Thunderbird booth, we dug into standards, shared hard-won lessons, debated solutions, and explored what's next for open communication tools.

The highlight, as always, was meeting users face-to-face. Hearing your stories about what's working, what's painful, and what you'd like to see next continues to be one of the most motivating parts of our work.

Several recurring themes stood out in these discussions, and we're keen to help move the needle on some of the bigger, knottier challenges, including:

These conversations don't end when FOSDEM does but help shape our priorities for the months ahead, and we're grateful to everyone who took the time to stop by, ask questions, or share their experiences.

Exchange Email Support

After releasing Exchange support for email to the Monthly release channel, we've had some great feedback and helpful diagnosis of edge case problems that we've been prioritizing for the past few weeks

Work completed during this period includes:

Work on supporting the Graph API protocol for email is moving steadily through the early stages, with these basic components already shipped to Daily:

Keep track of our Graph API implementation here.

Account Hub

The team met in person following FOSDEM and have planned out work to allow the new Account Hub UX to be used as the default experience in our next Extended Support Release this summer, which will ensure users benefit from changes we've made to enable custom Oauth settings and configuration specific to Microsoft Exchange.

Follow progress in the meta bugs for the last few pieces of phase 3 and telemetry, as well as the work we've defined to enable an interim experience for users setting up Thunderbird for the first time.

Calendar UI Rebuild

The new Calendar UI work has advanced at a good pace in recent weeks and the team met in person to break the work apart into chunks which have been prioritized alongside some of the "First Time User Experience" milestones. The team has recently:

Stay tuned to our milestones here:

Maintenance, Upstream adaptations, Recent Features and Fixes

Over the past couple of months, a significant portion of the team's time has gone into responding to upstream changes that have impacted build stability, test reliability, and CI. Sheriffing continues to be a challenge, with frequent breakages requiring careful investigation to separate upstream regressions from Thunderbird-specific changes.

Alongside this ongoing maintenance work, we've also benefited greatly from contributions across the wider development community. Thanks to that collective effort, a steady stream of fixes and improvements has landed.

More broadly and focusing on our roadmap, the last two months have seen solid progress on Fluent migrations, as well as planning and early groundwork for rolling out Redux and the Design System more widely across the codebase.

Support from the community and team has resulted in some notable patches landing in recent weeks, with the following of particular help:

If you would like to see new features as they land, and help us find some early bugs, you can try running daily and check the pushlog to see what has recently landed. This assistance is immensely helpful for catching problems early.

Toby Pilling

Senior Manager, Desktop Engineering

The post Thunderbird Monthly Development Digest: February 2026 appeared first on The Thunderbird Blog.

11 Feb 2026 5:50pm GMT

Support.Mozilla.Org: What’s up with SUMO – H2 2025

Hi everyone,

We may already be a few weeks into 2026, but it's never too late to say Happy New Year! As we dive into the year ahead, we also want to take a moment to reflect on everything we accomplished together in the second half of 2025.

In this recap, you'll find highlights from community campaigns, major platform updates and product launches, as well as forum and Knowledge Base data that offer a clearer picture of how the community performed. We hope this snapshot helps celebrate what went well, while also shining a light on areas where we can continue to grow together.

Let's jump in!

Highlights

Community stats

Forum Support

General stats

The forum continues to show encouraging signs of community growth and maturity. Most notably, the solve rate more than doubled, jumping by 124% to reach 11.9%. This is a clear signal that contributors are not only engaging with users, but successfully resolving their issues at a much higher rate. We also saw a 9.8% increase in OP reply rate, suggesting stronger two-way engagement between users and contributors.

Improvements in speed reinforce this trend: first response time dropped by nearly 30%, while time to resolution was cut in half, falling by 48.9%. Combined with a 12.7% rise in reply rate and 15.7% more threads being actively supported, these results point to a community that's not just growing, but becoming more efficient, responsive, and impactful.

With the automatic spam moderation introduced in the first half of year, we've seen fewer total questions coming in H2 2025 but higher quality interactions overall. This shift suggests a more focused and intentional support environment. Taken together, these trends suggest that it's time to elevate solve rate from a "nice to have" to a core success metric, a meaningful reflection of contributor expertise, community trust, and the maturity of our Community Forums.

Total valid questions 14803 (-20%)
Reply rate 63.5 (+12.67%)
Solve rate 11.9% (+124%)
Total responses posted 14191 (+20.4%)
Total threads interacted 9599 (+15.7%)
Average first response time (in hour) 22.4 (-29.8%)
Average time to resolution (in day) 2.55 (-48.9%)
Total new registration 455k (+0.5%)
Total contributors 963 (-1.3%)
Helpful rate 60.8% (+3.92%)
OP reply rate 27% (+9.8%)

Top forum contributors

All credit for this impressive performance goes to our incredible forum community, who continue to raise the bar with each quarter. Their dedication, consistency, and responsiveness are what make these results possible.

We're proud to highlight the top 3 contributors on the English forum, along with the leading contributors across other locales. This shows a true reflection of the global impact of our support network.

Contributor name Total responses Total threads engaged
Paul Wright (en-US) 1900 1395
Denyshon (en-US) 1284 924
Jefferson Scher (en-US) 930 871
@next (it) 557 438
Gerardo (es) 523 457
Mark Heijl (nl) 186 155
Selim (tr) 126 87
Ansamb (cs) 87 65
Poljos-moz (cs) 81 59
Sandromonteiro (pt-BR) 15 15
Balázs Meskó (hu) 51 48
Vexi (sl) 5 5

Emerging forum contributors

Contributor name Total responses Total threads engaged
George Kitsoukakis 202 171
Mark 136 110
sjohnn 65 45
t.r.ernst 64 60
Jeff-g 61 54

Knowledge Base

General stats

We've seen an impressive uptick in article contributions in the second half of 2025, with 925 revisions submitted to the English Knowledge Base, a 21.9% increase compared to the previous period. This continued growth reflects not just dedication, but real momentum of the growing spirit to keep our Knowledge Base fresh and helpful for users worldwide.

This level of participation directly supports our broader direction towards improving and streamlining the content request workflow. As we continue investing in clearer processes and better documentation, it's clear that contributors are willing to step up when the pathway to impact is well defined.

Total en-US revisions 925 (+21.9%)
Total articles 248 (+2.9%)
Total revisions reviewed 821 (+19.9%)
Total revisions approved 778 (+17.7%)
Total authors 97
Total reviewers 19 (+11.8%)

Top KB contributors

The numbers may show progress, but the real story is the people behind them. Behind these revisions, 97 unique contributors stepped in to create the updates and 19 reviewers helped guide their contributions. And here's just a glimpse of the top 5 contributors:

Contributor name Total revisions Total articles Total reviews
AliceWyman 467 246 334
Pierre Mozinet 125 100 -
Mark Heijl 101 88 -
Michele Rodaro 50 46 35
Paul Wright 26 21 5

Article Localization

The localization community delivered an outstanding performance in H2 2025, despite undergoing significant changes. We saw 4807 non-English revisions submitted, a 37.5% increase, covering 2664 articles across locales (+29.7%). In total, 4,259 revisions were approved and 4,296 reviewed, reflecting consistent contributor dedication to quality and accuracy. Most notably, 314 unique contributors stepped up to author content, representing a 54.7% increase from earlier this year.

These results are especially meaningful given the rollout of Machine Translation in August, a major shift in localization workflow that understandably sparked concern and discussion across the community. Adjusting to MT required both flexibility and trust, and we're grateful that many contributors responded by showing up in full force. Your continued involvement ensured that translations remained thoughtful, context-aware, and aligned with Mozilla's values of openness and quality. This success is a testament to the strength, resilience, and care of our contributor base, and we're deeply grateful for your ongoing contribution.

General stats (minus sumoBot)

Total non en-US revisions 4807 (+37.5%)
Total articles 2664 (+29.7%)
Total revisions reviewed 4296 (+33.5%)
Total revisions approved 4259 (+33.6%)
Total authors 314 (+54.7%)
Total reviewers 45 (-6%)

Top localization contributors

Contributor name Total revisions Total articles Total reviews
Michele Rodaro (it) 819 393 801
Jim Spentzos (el) 727 566 555
Valery Ledovskoy (ru) 627 400 635
Mark Heijl (nl) 575 359 -
Milupo (dsb & hsb) 460 224 330

Emerging localization contributors

Contributor name Total revisions Total articles
普莱是袋熊 (zh-CN) 35 31
Zhengyang3552 (zh-CN) 22 21
xanhAD (vi) 13 11

Stay connected with the community

Join the Conversation

Attend Our Monthly Community Call

Stay Informed

Explore What We're Building

You can also view our latest release notes to stay informed about recent changes and improvements.

11 Feb 2026 7:00am GMT

Niko Matsakis: Dada: moves and mutation

Let's continue with working through Dada. In my previous post, I introduced some string manipulation. Let's start talking about permissions. This is where Dada will start to resemble Rust a bit more.

Class struggle

Classes in Dada are one of the basic ways that we declare new types (there are also enums, we'll get to that later).

The most convenient way to declare a class is to put the fields in parentheses. This implicitly declares a constructor at the same time:

class Point(x: u32, y: u32) {}

This is in fact sugar for a more Rust like form:

class Point {
    x: u32
    y: u32
    fn new() -> Point {
        Point { x, y }
    }
}

And you can create an instance of a class by calling the constructor:

let p = Point(22, 44) // sugar for Point.new(22, 44)

Mutating fields

I can mutate the fields of p as you would expect:

p.x += 1
p.x = p.y

Read by default

In Dada, the default when you declare a parameter is that you are getting read-only access:

fn print_point(p: Point) {
    print("The point is {p.x}, {p.y}")
}

let p = Point(22, 44)
print_point(p)

If you attempt to mutate the fields of a parameter, that would get you an error:

fn print_point(p: Point) {
    p.x += 1 # <-- ERROR!
}

Use ! to mutate

If you declare a parameter with !, then it becomes a mutable reference to a class instance from your caller:

fn translate_point(point!: Point, x: u32, y: u32) {
    point.x += x
    point.y += y
}

In Rust, this would be like point: &mut Point. When you call translate_point, you also put a ! to indicate that you are passing a mutable reference:

let p = Point(22, 44)     # Create point
print_point(p)            # Prints 22, 44
translate_point(p!, 2, 2) # Mutate point
print_point(p)            # Prints 24, 46

As you can see, when translate_point modifies p.x, that changes p in place.

Moves are explicit

If you're familiar with Rust, that last example may be a bit surprising. In Rust, a call like print_point(p) would move p, giving ownership away. Trying to use it later would give an error. That's because the default in Dada is to give a read-only reference, like &x in Rust (this gives the right intuition but is also misleading; we'll see in a future post that references in Dada are different from Rust in one very important way).

If you have a function that needs ownership of its parameter, you declare that with given:

fn take_point(p: given Point) {
    // ...
}

And on the caller's side, you call such a function with .give:

let p = Point(22, 44)
take_point(p.give)
take_point(p.give) # <-- Error! Can't give twice.

Comparing with Rust

It's interesting to compare some Rust and Dada code side-by-side:

Rust Dada
vec.len() vec.len()
map.get(&key) map.get(key)
vec.push(element) vec!.push(element.give)
vec.append(&mut other) vec!.append(other!)
message.send_to(&channel) message.give.send_to(channel)

Design rationale and objectives

Convenient is the default

The most convenient things are the shortest and most common. So we make reads the default.

Everything is explicit but unobtrusive

The . operator in Rust can do a wide variety of things depending on the method being called. It might mutate, move, create a temporary, etc. In Dada, these things are all visible at the callsite- but they are unobtrusive.

This actually dates from Dada's "gradual programming" days - after all, if you don't have type annotations on the method, then you can't decide foo.bar() should take a shared or mutable borrow of foo. So we needed a notation where everything is visible at the call-site and explicit.

Postfix operators play more nicely with others

Dada tries hard to avoid prefix operators like &mut, since they don't compose well with . notation.

11 Feb 2026 12:29am GMT