Add 2026Q2 roadmap

docs/en/news/posts/2016/buzz/money-money-money.md

@@ -85,15 +85,15 @@ When this is done in front of a live audience, at each question, there are fewer
 
 So what's going on here? Well, it reflects 2 different ways of looking at a piece of software - Projects and Products. And it's a matter of personal perspective - my project can be your product, and vice versa.
 
-When I view some code as a project, it's a body of code where I'm contributing to a larger goal. I'm willing to spend resources focussing on other people's needs in the hope that their needs will help make the project as a whole better. I'm willing to do this because I get some personal gain, like an enhanced public profile; or if the tool is really close to my work coalface; or where I know I can make a substantive contribution.
+When I view some code as a project, it's a body of code where I'm contributing to a larger goal. I'm willing to spend resources focusing on other people's needs in the hope that their needs will help make the project as a whole better. I'm willing to do this because I get some personal gain, like an enhanced public profile; or if the tool is really close to my work coalface; or where I know I can make a substantive contribution.
 
 But the further I get away from my coalface, and the harder it is to make a contribution, the less inclined I am to even *want* to contribute to the project. Most of the time, it's a product that I'm using, warts and all. If a product has bugs, I'll work around them, or find an alternative, rather than navigating the contribution process and contributing a patch back upstream.
 
 In the case of a product, the freedoms afforded by Free software are a bit like freedom of speech - it's a freedom I definitely want, it's comforting to know it's there, but I don't spend every day making sure that I fully exploit the extents of those freedoms. There are people who do - protestors, advocates for controversial social positions - and one day, given the right circumstances, I might join in and help them. But most of the time, I just want to be pragmatic, and get on with living.
 
 This dichotomy between the theory and practice is also the reason why comments like "Patches Welcome" get made in Free software mailing lists. On the one hand, it's completely correct. Anyone *can* contribute, and on most projects *patches* are welcome. But most people don't look at a new open source project as an opportunity to engage and contribute. Most people just want to use the damn software.
 
-And you can argue it's because people are focussing on the wrong interpretation of "free", and haven't "captured the spirit of free software". Which is 100% true, but utterly counterproductive as a position. Anyone who has done any UX work knows that if users are consistently making a mistake, blaming the user gets you nowhere. You were in charge of what the user experienced, and they made the "error" because of a fundamental cognitive disconnect.
+And you can argue it's because people are focusing on the wrong interpretation of "free", and haven't "captured the spirit of free software". Which is 100% true, but utterly counterproductive as a position. Anyone who has done any UX work knows that if users are consistently making a mistake, blaming the user gets you nowhere. You were in charge of what the user experienced, and they made the "error" because of a fundamental cognitive disconnect.
 
 And even if everyone *did* get the right message - let's be realistic - it wouldn't work anyway. The mythical man month showed us that you don't deliver a project faster or better by throwing more people at it. 9 women can't make a baby in 1 month - a project doesn't just need resources - it needs the *right* resources, in the right quantities. And ultimately, that means projects finding a way to get the resources they need to be self-sustaining.
 

docs/en/news/posts/2022/buzz/april-2022-status-update.md

@@ -32,7 +32,7 @@ Many of these PRs either began as, or are entirely the work of community members
 
 ## What's next?
 
-In May, we'll be focussing on:
+In May, we'll be focusing on:
 
 - Updating the support packages for macOS and iOS apps. Apple's transition to M1 hardware means there are new simulator architectures that require support; this, in turn, requires that we adopt Xcode's new XCFramework for the packaging libraries, which requires some fairly major changes to the way the support packages are built.
 - Updating the support packages on Android to support Python 3.10.

docs/en/news/posts/2022/buzz/june-2022-status-update.md

@@ -28,7 +28,7 @@ During June:
 
 ## What's next?
 
-In July, we'll be focussing on:
+In July, we'll be focusing on:
 
 - Completing the work on Linux and Windows application packaging.
 - Presenting a webinar about native application development. If you'd like to attend, [registration for this webinar is open](https://event.on24.com/wcc/r/3766379/B50F020E006CF935D87609BF3E247ED7?partnerref=anaconda.com)

docs/en/news/posts/2022/buzz/may-2022-status-update.md

@@ -29,7 +29,7 @@ Many of these changes either began as, or are entirely the work of community mem
 
 ## What's next?
 
-In June, we'll be focussing on:
+In June, we'll be focusing on:
 
 - Publishing our roadmap for Q3 and beyond! Now that we have reliable development resources, we're in a position to make public commitments on the future direction of the project.
 - Completing the hiring process for another engineer to work on BeeWare full time. This hiring process is underway, but it's not too late to apply if you're interested. Full details of the position can be found on Greenhouse.

docs/en/news/posts/2024/buzz/2024q4-roadmap.md

@@ -19,7 +19,7 @@ We've also made significant progress on binary packaging. We've backported all t
 
 ## Q4 priorities
 
-In Q4, we'll be focussing on the tools and documentation needed to for third-party Python packages to add Android and iOS support to their official CI and release processes. In addition to contributing to tools like `pip` and `cibuildwheel`, we'll develop the tools and documentation needed so that it is easy to add CI configurations for mobile platforms. The hope is that by the end of the year, there will be at least one third-party package that produces Android and iOS wheels without any direct involvement of the BeeWare team.
+In Q4, we'll be focusing on the tools and documentation needed to for third-party Python packages to add Android and iOS support to their official CI and release processes. In addition to contributing to tools like `pip` and `cibuildwheel`, we'll develop the tools and documentation needed so that it is easy to add CI configurations for mobile platforms. The hope is that by the end of the year, there will be at least one third-party package that produces Android and iOS wheels without any direct involvement of the BeeWare team.
 
 ## Longer term goals
 

docs/en/news/posts/2025/buzz/august-2025-status-update.md

@@ -35,7 +35,7 @@ September will involve a lot of travel - we'll be attending [PyCon AU](https://2
 
 When we're not traveling, we're going to continue working on getting iOS binary artefacts into Python's CI and release processes, and on improving the tools for packaging binary wheels for mobile platforms.
 
-Lastly, we're planning to look at adding post-install scripts to Briefcase installers. We'll be focussing on Windows installers initially; but the intention is that any changes we implement could also be implemented on macOS or Linux.
+Lastly, we're planning to look at adding post-install scripts to Briefcase installers. We'll be focusing on Windows installers initially; but the intention is that any changes we implement could also be implemented on macOS or Linux.
 
 ## Want to get involved?
 

docs/en/news/posts/2025/buzz/july-2025-status-update.md

@@ -37,7 +37,7 @@ With `cibuildwheel` now supporting both iOS and Android, our work on binary pack
 
 We're also going to continue the process of integrating the production of iOS and Android binary artefacts into Python's CI and release processes. We've already begun this process for Android; iOS requires a little more preparatory work, which will be a major area of focus in August.
 
-Lastly, we're planning to look at adding post-install scripts to Briefcase installers. We'll be focussing on Windows installers initially; but the intention is that any changes we implement could also be implemented on macOS or Linux.
+Lastly, we're planning to look at adding post-install scripts to Briefcase installers. We'll be focusing on Windows installers initially; but the intention is that any changes we implement could also be implemented on macOS or Linux.
 
 ## Want to get involved?
 

docs/en/news/posts/2026/buzz/2026q2-roadmap.md

@@ -0,0 +1,48 @@
+---
+title: 2026Q2 Roadmap
+date: 2026-04-20
+authors:
+- freakboy3742
+categories:
+- Buzz
+---
+
+Q1 has seen some significant improvements to Toga, Android packages, and a milestone for official iOS support. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment to features that will be made available on a specific deadline.
+
+<!-- more -->
+
+## Q1 progress
+
+The bulk of our activity in Q1 has focused on Toga. We completed work on Toga's new Qt backend, achieving full widget coverage. We made some significant improvements to the API for managing columns in Tree and Table widgets. On Windows, we've added an implementation of a Tree widget for the first time, and significantly improved the Table widget. We made a major change to how widgets are imported, improving load times for Toga apps, and allowing third-party libraries to register their own widgets and their own implementations of existing widgets. We also performed a major refactor of the Canvas widget API, improving consistency between Toga's Python API and the HTML5 Canvas API that we use as a reference implementation.
+
+We also made improvements to Toga's Positron plugin. Positron is Toga's answer to Electron - a way to build cross-platform apps where the user interface is provided by a web page. However, Positron allows you to use Python web servers rather than JavaScript - and unlike Electron, allows for the development of hybrid applications and mobile application. This quarter, we added the ability to deploy a FastAPI website; improved the tooling for building an app from an existing website; and we've built a prototype of a new PyScript backend that allows client-side browser code to access server-side capabilities.
+
+However, the biggest Toga news for the quarter is that we laid out a design plan for the next phase of Toga's development, addressing issues of "Big Picture" app design. The set of widgets offered by Toga is reasonably complete for most platforms. At this point, the issue facing application developers - especially on mobile platforms - is how to represent navigation between content in a large app. After some public discussions, we've laid out a plan for a range of improvements that should enable users to write reasonably complex applications in Toga, while retaining cross-platform, single source base compatibility. This plan will form the basis of Toga development for the coming months.
+
+Work on Android wheels has progressed. We have published updated internal Android wheels for a number of key data science packages, including NumPy, Pandas, SciPy, scikit-learn and xgboost. Developing these patches involved developing updates to a variety of tools that are used to build wheels, including `cibuildwheel`, `auditwheel`, Meson, and Python's own Android testbed. The patches resulting from this work take time to get upstream; that work will proceed in the background over the coming months.
+
+We have completed the work adding iOS to CPython's release artefacts. As a result, Python 3.15.0b1 should include an official CPython iOS XCFramework that can be incorporated into an iOS project. As part of this work, we've also assisted with a large cleanup of the CPython repository, moving all the platform-specific build tooling for iOS, Android and Emscripten into a single "Platforms" directory. Along the way, we've addressed some minor inconsistencies and usage issues with these build scripts.
+
+We released Briefcase 0.4.0, which includes a major improvement to the operation of development mode operates for apps, isolating the dependencies of the app being developed from the environment that is running Briefcase. It also includes support for PEP 639 license specifications - part of an ongoing effort to align Briefcase metadata with PEP 621. We've also started experimenting with the use of `ty` to enforce type annotations in Briefcase's code.
+
+After some discussion by the team, we've made the decision to adopt an AI Contribution policy. This policy adopts a neutral stance on the use of AI tooling; however, it requires formal declaration of AI tool usage, and makes it clear that the humans driving autonomous tools are ultimately responsible for the output of those tools. The policy is currently in the final stages of getting approval from the team; we expect to roll out the policy in the next couple of weeks.
+
+Lastly, we released our new project website. The content of this website isn't significantly different to before - but it now uses the same MkDocs tooling that we use for all our other documentation, giving us much faster builds, better translation tooling, search... and dark mode! It also includes translations to some new languages, including Japanese and Russian.
+
+## Q2 priorities
+
+In Q2, we have two main priorities.
+
+Firstly, we'll be focusing on some key improvements to Briefcase. We intend to continue improving Windows MSI installers, adding some additional customization options, and adding support for Windows on ARM64. We plan to start investigating the use of Conda environments for building Briefcase apps. Lastly, we will explore mechanisms for updating the content of an existing app without having to go through an App Store review cycle. This may also open options for "live reload" of app development.
+
+Secondly, we plan to start executing on the "Big Picture" plan that was laid out in this quarter. That plan describes a lot of changes, so we don't anticipate completing that plan for some time. However, we're hoping to see some progress on the foundational pieces of that work, which we will build on over the course of the year.
+
+We will also be attending [PyCon US](https://us.pycon.org/2026/schedule/presentation/36/). We're presenting talks on [mechanisms for distributing Python code](https://us.pycon.org/2026/schedule/presentation/36/) and [switching your project documentation from Sphinx to Markdown](https://us.pycon.org/2026/schedule/presentation/6/). We'll be there for [both days of the sprints](https://us.pycon.org/2026/events/dev-sprints/), as well as participating in a number of other events and generally lurking around the hallways. If you're able to make it, make sure you say hello!
+
+## Longer term goals
+
+Now that we've published a plan for "Big Picture" app development, our primary long term goal is to deliver on that plan.
+
+Along the way, we're not going to ignore Briefcase. Briefcase already solves a number of key distribution problems in the Python ecosystem; but there's a lot of opportunity to further improve alignment with Python ecosystem standards, simplify the process of developing apps, and streamline publication of apps into app stores.
+
+However, there's only so much the core team can do by ourselves. The ultimate long term goal is to build the community of BeeWare users and developers so that the core team isn't the only source of new features and support. Part of the reason we spent time publishing a plan for Toga's future development rather than just doing the work ourselves is to enable community contribution. We hope to do more of this community-enabling work over the coming months.

docs/spelling_wordlist

@@ -222,7 +222,6 @@ else's
 embeddable
 enquiries
 enquiry
-focussing
 foosball
 frontend
 fuddy

tox.ini

@@ -8,6 +8,8 @@ docs_dir = {tox_root}{/}docs{/}en
 # Docs are always built on Python 3.13. See also the RTD config.
 base_python = py313
 skip_install = true
+setenv =
+    DISABLE_MKDOCS_2_WARNING = true
 passenv =
     DEEPL_API_KEY
 dependency_groups = docs