If you’d like to contribute to PyBaMM whether via reporting issues and bugs, updating the documentation, or adding new features (thanks!), please have a look at the Contributing Guidelines.
We communicate what we are working on in two different ways:
The roadmap is a static document indicating the broad directions in which we intend to develop the project.
The roadmap is reviewed and updated once every four months, at the same time as new releases are made. Following every release, we hold a public event where we go over what changes have been made in that release, as well as updates to the roadmap. For more details, see the Roadmap page.
Specific things that we are currently working on are indicated by issue labelling and assignment.
Anyone can open an issue. To indicate our response to any given issue, we use the following categories for triaging:
Priority is decided based on criticality (for bugs) and alignment with the roadmap (for features). Issues that are not within scope of the project will be closed.
We work in one-month sprints. At the monthly maintainer meeting, we assign tasks to be completed by each maintainer for the following month. We assign issues in decreasing order of priority, using the difficulty to judge how long each issue will take. For example, each maintainer may be assigned one hard issue, or five medium ones, or twenty easy ones, or a mix. Any issues that come up during the month will be triaged at the following triaging meeting.
In some cases, we need more information about the issue before we can judge the priority level and difficulty (or even understand the root cause and hence fix it). In this case, the issue will be marked with a “needs-reply” tag. If there is no response within 30 days, the issue will be closed.
Everyone is expected to give an update on the issues they have been assigned either synchronously at the monthly developer meeting or asynchronously by commenting on the issue before the meeting. If no update is given for two consecutive months then the issue is deemed to have been abandoned and will be assigned to someone else (possibly one month for some high-priority issues).
There are many ways to contribute to setting the direction of the project, beyond just code.
Look for unassigned issues labelled “priority:high” or “priority:medium”, and volunteer to take them on (either synchronously at the meeting or asynchronously before).
Look for unassigned issues labelled “difficulty:easy” and volunteer to take them on. Come to the monthly newcomers meeting to discuss issues or for help getting started.
If you work for a company that uses PyBaMM and would like to sponsor the project to ensure its continuing development, there are several ways you can help:
Recurring donations without a specific deliverable. Donations are acknowledged on public project pages, and opportunities for interaction with the core development team. See our GitHub sponsor page for details.
Check out our Donate page for more details about sponsorship and payment options.
While the roadmap is mainly decided by the core team (maintainers and steering council), you can donate to have issues moved up in priority via Community Work Orders. The price depends on issue difficulty and current priority. Get in touch to find out more.
We are experimenting with this process and always looking for ways to improve our workflow. If you have any feedback on this process or ideas for how we can improve, please get in touch either by opening a discussion on GitHub or emailing us at pybamm@pybamm.org.
The PyBaMM team offers mentorship and funding opportunities under several open-source programs regulated by other organisations. These programs are an amazing opportunity for students and professionals to work on PyBaMM and get familiar with various open-source practices. More information on the open-source programs can be found on the dedicated Open-Source Programs page.