About Plan Zero
An independent research project to model how Canada might achieve zero net emissions
Table of Contents:
About this project
PlanZero is an independent research project to model how Canada might achieve zero net emissions. The long-term vision is that it can quantify the opportunities associated with strategies — such as public and private research and development efforts, and public policies — and situate them in comprehensive long-term scenarios based on projections of Canada's possible future climate, population, energy supply, and other macro trends that might influence future emissions.
There have been, and thankfully continue to be, many efforts to model future emissions in the world: the effect they have on the climate, and the effect various technologies may exert on emission rates. As I build up a bibliography (not yet started as of April 2026) this PlanZero site will situate itself in the context of ongoing and previous work. I believe that PlanZero is differentiated from other efforts in (a) focusing on Canada, and (b) in being structured as an open-source software project. I hope, over time, that because of this differentiation, it may engage the community of Canadian students at undergraduate and graduate levels:
- to help some learn about the diverse challenges of transitioning to a net-zero economy
- to help some build compelling models of strategies that can and should be put into action
- to help some learn about participating in distributed open projects
- to help some learn about software engineering, architecture, and statistical modelling
As the project matures in depth and breadth, I hope it becomes a resource that can help shape public policy, and guide capital investment into research and technology development.
Contributors
- Myself, James Bergstra, the project's lead author and developer. James is supported by his long-suffering wife, who endures the first drafts of so many posts, provides invaluable feedback and support, and wishes to remain anonymous.
- Professor Seth Wynes, Ph.D., an Assistant Professor in the Department of Geography and Environmental Management at the University of Waterloo. Seth is guiding James' transition into the world of climate modelling and communication.
- The Opt2Refuture team. The group, of which James is a member, has provided research leads, post feedback, and a forum for discussion of issues related to emissions reduction in Canada.
Guidance Re: Posts
I think of the PlanZero project in terms of the following facets:
- code (GitHub) - the state and history of all data, code, and content, in git
- issues (GitHub) - a set of likely next steps, a rough roadmap
- posts - a narrative history of the development of the PlanZero site
- about - project overview, direction, acknowledgements
- rest of PlanZero site - the summary of PlanZero modelling and research
- Focus: posts tie code changes to justifiable improvements to the site content
- Convenience: posts make it convenient and comfortable for people to follow project developments without visiting the planzero site
- Accessibility: provide a narrative history and onboarding tool so people can tune in as the project develops, even as the site content gets more complicated and elaborate
Preface: Revision Control as Mechanism and Inspiration
As a preface to explaining how posts are supposed to work in PlanZero, it is worth saying how revision control, and git in particular, have at least revolutionized, if not fundamentally enabled, open-source software. Open-source software is developed in many ways, but the most canonical style is by a loosely-organized community of contributors, each of whom has a copy of the software (called a branch, or fork of the code), and can develop it however, and whenever they please (by making commits of changes to their branch). Development would not be efficient, if not for revision-control systems that allow such developers to stitch their private improvements back together into a coherent, improved, software system (this stitching is called a merge in git). Despite challenges such as weak coordination and predictable governance issues, open-source communities have developed and maintained some of the most complex and most stable software in the world, including git itself (of course), the Linux operating system, simulation tools for mathematical modelling, and many models used for atmospheric, ocean, and climate science.
This pattern applies at two conceptual levels with regards to PlanZero. As a lower level, PlanZero follows this pattern, by using git via GitHub. As a higher level, PlanZero uses posts to mark significant changes to the underlying project code, including the structure and visualizations elsewhere in the site. At this higher level, the rest of the site is like the "coherent, improved software system" with an ever-expanding set of models, visualizations, analyses etc. that nevertheless remain internally consistent; and the posts narrate the incremental changes that have lead from the start of the project to the current state. PlanZero's git history also includes a sort of narrative of commit messages, but these messages are small, text-only, and not written for the audience of the site itself.
The Purpose of Posts
With the preface stated, the purpose of posts can be stated more succinctly: it is to document why and how something elsewhere on the site has changed. Typically both the post and the change-elsewhere are part of a combined implementation effort (what might naturally be a branch, in git), that is merged together into the main project branch. Git commit messages should describe and justify the changes associated with each git commit in language familiar to a project contributor. A git pull request on GitHub should describe and justify an entire branch worth of changes in language oriented to a project contributor. Such a branch and pull request should include at least one new post that describes and justifies the entire branch worth of changes to anyone visiting the PlanZero site.
The following table compares and constrasts the various summaries that arise in the course of working on PlanZero:
| summary | git association | scope | audience |
|---|---|---|---|
| GitHub pull request | branch | one per site improvement | contributor / developer |
| PlanZero post | branch | at least one per branch | site visitor |
| git commit message | commit | typically many per branch | contributor / developer |
A corollary to this bit of guidance, is that if there is no visible change to the site other than the post itself, then there is nothing beyond the post itself in need of explanation, and arguably there should be no post at all. For example, a communication of the form "Group of people X should do Y instead of Z" should generally not be a post on PlanZero (unless e.g. the group of people is PlanZero contributors and the post is about a change to the About page). The closest message might be something like "Because of some new modelling or data added to PlanZero, we see that if group of people X did Y instead of Z, it would change such-and-such impact from A to B." In future there may be a "Perspectives" or "Recommendations" section with examples of using PlanZero to weigh in on public debate, but there is not yet such a section.
Draft Status
A post can have a status of "Draft". This status determines how the post should be displayed, and how it may be revised. The purpose of these policies is to respect the PlanZero audience's time. After someone has generously volunteered their time and energy to understanding a post on PlanZero, it would be rude of us to confuse them or devalue what they've understood by changing the content of a page after they've read it.
If a post is a draft, then
- the word "DRAFT" appears in large letters in the title, wherever it appears
- the text of the post is subject to change without notice
- the entire post may be hidden, withdrawn, removed, etc.
- no such word such as "DRAFT" appears in the title
- it should never be materially changed
- if it is superceded, it should be amended to include a link to the new post introducing the superceding content
Moving a post from draft to non-draft status is the occasion for broader communication. In future a post leaving draft status may somewhat automatically lead to broadcast on e.g. mailing list, substack, X (twitter), slackbot, facebook, LinkedIn, and/or other ways of getting messages out, but I haven't decided how to handle that yet. For now I'll transmit posts manually, in an ad-hoc manner.
Post Dates
Posts have dates, but those dates should be interpreted as approximate. The dates of posts should be set to create a coherent narrative, and reflect the approximate time that work was done. The date of a post need not reflect the time the work was started, completed, or last edited.
When a non-draft post is amended to include a link to a superceding post, the amendment should mention a date e.g. "(Edited April 25, 2026: new post X covers this topic differently...)" but this date too can be approximate.
PlanZero's git history has a precise history of which files were edited in what ways on which dates and times. This history is detailed and accurate, although it reflects the development process commit-by-commit rather than the narrative presented by the posts.
Post Authorship and Acknowledgements
Post authorship and acknowledgements should follow what I think of as academic convention, which is to say that it's not easy to articulate a policy. At one end of a spectrum: someone that has done all of the work and written the post itself is typically an author. At the other end of that spectrum: a funding agency with little knowledge of the work is typically recognized via acknowledgement. In between, it's case by case management of contributor and audience expectations, project precedent, and community conventions.
Page, Post, and Link Lifetime and Durability
Generally, pages hosted under https://planzero.ca are not guaranteed to remain as they are. They may be improved, but they may also change to mean slightly different things, be separated across multiple pages, joined together, or disappear entirely. If a page is simply moved to a new path, the old path may or may not re-direct to the old one.
The exception to this general rule is the posts: The posts should remain at their urls, and continue to feature the same content that they had when they left "Draft" status.