MNE-Python

MNE-Python - Logging and String Formatting Standardization

About the Open Source Project

MNE-Python is an open source Python library that enables researchers to conduct rigorous neuroimaging studies by replacing fragmented, proprietary tools with a free, reproducible, and scalable solution grounded in modern software practices. It addresses a major challenge in neuroscience and clinical research: analyzing, processing, and visualizing electrophysiological data such as MEG (magnetoencephalography), EEG (electroencephalography), and other related neuroimaging modalities.

Users

Neuroscientists, cognitive psychologists, and biomedical engineers conducting brain research.
Clinical researchers and professionals in neurology and psychiatry.
Graduate students and postdocs learning MEG/EEG analysis.
Educators using it to teach neuroimaging and signal processing.
Industry researchers building brain-computer interfaces (BCIs) and neurotech applications.

Contributors

An active international community of researchers, developers, and educators.
Core contributors are affiliated with institutions like University of Washington, MIT, INRIA, Martinos Center, and Google Research.
Many contributions come from academic labs using MNE-Python in their own work, ensuring alignment with real-world scientific needs.

MNE-Python’s development is community-driven and emphasizes reproducibility,
accessibility, and open science.

About the Project with POSSEE

The proposed project addresses a key maintainability challenge in the codebase: inconsistent and outdated string formatting practices.
Specifically:

Logging messages in MNE-Python currently use f-strings in some places, which violates best practices for Python logging. This can lead to performance inefficiencies and runtime errors when logs are disabled or misused.
Elsewhere in the codebase, legacy %-style substitutions (%s, %d, %f) are still common. These reduce readability and hinder new contributors who are more familiar with modern Python f-strings.

These inconsistencies create technical debt and raise the barrier for community contributions.

What impact will this project make?

Users

Users will benefit from improved reliability and performance in logging behavior.
More consistent error reporting and debugging tools mean fewer bugs slipping through during development and testing.

Developers

The codebase will become easier to read, maintain, and extend, especially for new contributors.
Adoption of consistent formatting will help developers reduce confusion around logging behavior.
It reinforces a shared standard that boosts team efficiency and collaboration.

Ecosystem

This project strengthens MNE-Python as a model for clean, modern scientific Python code, supporting downstream projects and the broader open science ecosystem.
It builds a bridge between educational programs and real-world open source work, ensuring long-term sustainability by growing the next generation of contributors.

In short, this project tackles a tangible, well-scoped issue that unlocks broader benefits in code clarity, contributor onboarding, and sustainable open science development.

Project’s Scope

1. Standardize logging messages

Enable the linter rule G004 (https://docs.astral.sh/ruff/rules/logging-f-string/) to disallow f-strings in logging calls.
Configure ruff to recognize internal `warn` command as a logging command to flag lines as failing lint using the `lint.logger-objects` setting.
Audit and refactor all log lines that use f-strings to use either %s substitutions or the `extras` kwarg.

2. String Formatting Refactor

Identify and replace legacy `%`-style formatting (e.g., `%s`, `%d`, `%f`) with f-strings, where not used for logging or date/time formats.
Review and update as needed formatting strings across the codebase.
Audit project tutorials and documentation for similar patterns.

Measuring Project’s Success

We will evaluate the success of the project through a combination of quantitative metrics, code quality indicators, and community engagement outcomes:

1. Completion of Defined Technical Goals

All logging messages using f-strings are refactored (approx. 33 identified cases).
ruff linter rule G004 is enabled and `warn` is properly configured as a recognized logging function.
All identified instances of `%s`, `%d`, `%f`, etc. outside of logging are refactored (approx. 243 cases).
Code passes all existing tests and new tests are added as needed.

2. Code Quality and Tooling

Zero violations of rule G004 and legacy string formatting patterns after project completion.
Integration of formatting conventions into automated linting and CI pipelines.

3. Learning and Contribution Outcomes

POSSEE interns submit high-quality pull requests, engage in meaningful code reviews, and demonstrate increased confidence in working with production-grade code.
Interns document their work clearly (e.g., through commit messages, issues, and blog posts).

Measuring Project’s Success

Basic knowledge of Python
Familiarity with logging and formatting in Python
Git and GitHub workflows
Basic experience with static analysis tools (e.g., Ruff, linters)

Previous Participation in Mentorship Programs

MNE-Python has a strong track record of participating in programs similar to POSSEE, including: Google Summer of Code (GSoC), Outreachy, and Open Science workshops.
Building on the past experiences, the MNE-Python team brings a well-established framework for mentoring new contributors:

We have refined the Contributing Guide to help new developers get started from Day 1.
We prioritize supportive, async-friendly mentorship, understanding that contributors may have diverse backgrounds, schedules, and learning styles.
The proposed project yields real impact for MNE-Python while being attainable to complete by early-career contributors.

MNE-Python

MNE-Python - Logging and String Formatting Standardization

Get Involved With POSSEE

Quick Links

Get In Touch

Follow Us