Skip to content

A Brave New World

Jump to bottom
Casper van Elteren edited this page Jan 17, 2025 · 1 revision

In the beginning there was Luke -- and we, his humble followers, will continue the journey that he set out years ago.

This is to brainstorm on setting some new guidelines for the future of this project, proplot -- renamed ultraplot. To shift the load to a truly FOSS experience, I will for the time being act as an in promptu benevolent dictator if you will. The goal is to set this project back on its feet and bring it back to the community while recognizing the work done perform.

We strive to

  • Produce high quality, readable code that compliments and enhances the matplotlib experience.
  • Keep up with the latest matplotlib development to prevent deprecation
  • Be cordially and civil to one another -- we are all here on our spare time writing some code for all of you.

What ultraplot is and what it isn't

  • It isn't an mpl replacement
  • It is an mpl enhancer with sensible defaults to produce beautiful scientific plots

Contribution and review To facilitate a quicker turn around on development, we need to expand people that can commit PRs. This requires defining a list of guidelines that would satisfy a commit being included in the codebase without adding rubbish to it. This means we need to be precise, but not preventative of allowing change. Responsibility is key and we aim to improve all the users experience by having mutual accountability to the developers, but also to the users.

Here are some guidelines

Ultraplot Contribution and Code Review Guidelines

Contribution and Review Guidelines

  1. Code Reviews Should be Constructive and Respectful

    • Focus on the code, not the person. Critique should aim to improve the codebase and help contributors grow.
    • Offer suggestions for improvement with clear reasoning and, when possible, alternative solutions.

  2. Emphasize Consistency and Style

    • Follow established coding standards and project conventions.
    • Avoid introducing stylistic changes unrelated to the purpose of the PR unless explicitly stated and approved.

  3. Document Changes Thoroughly

    • Ensure all public-facing functionality includes or updates relevant documentation.
    • For non-trivial changes, include clear comments and explanations within the code.

  4. Require Tests for New Features and Bug Fixes

    • Ensure that all new features are accompanied by unit tests demonstrating their correctness.
    • Fixes for reported issues should include tests that validate the resolution of the problem.

  5. Encourage Backward Compatibility

    • Avoid breaking changes unless absolutely necessary. When unavoidable, document the change thoroughly and provide migration guidance.

  6. Align with Ultraplot’s Mission

    • Ensure the proposed changes align with Ultraplot’s goal to enhance, not replace, Matplotlib.
    • Consider whether the change introduces sensible defaults that simplify and beautify scientific plotting.

  7. Address Deprecations and Maintain Compatibility

    • Regularly verify that the code is compatible with the latest Matplotlib versions.
    • Remove deprecated or unused features thoughtfully, and only after providing adequate notice.

  8. Collaborate Early and Often

    • Contributors should engage with maintainers early in the development process for significant or potentially contentious changes.
    • Proposals for large changes should include a brief design document or discussion in the project forum.

  9. Simplify Where Possible

    • Strive for simplicity in implementation and interface design. Avoid adding features unless they address a clear need or enhance usability significantly.
    • Reviewers should encourage contributors to refactor unnecessarily complex code.

  10. Be Pragmatic with Perfection

    • While high-quality code is the goal, don’t let perfect become the enemy of good. Allow room for incremental improvement.

  11. Timeliness and Communication

    • Reviewers should aim to provide feedback within a reasonable timeframe.
    • Contributors should be responsive to feedback and willing to iterate until the changes are satisfactory.

  12. Respect the Community and the Mission

    • Uphold the spirit of open source: mutual accountability, collaboration, and respect for all participants.
    • Remember that every contributor, reviewer, and user is here to make science more accessible and visually engaging.
Clone this wiki locally